From: Coby Beck
Subject: read, socket-streams and #\Backspace
Date: 
Message-ID: <CP5m7.56458$8c3.12522236@typhoon.tampabay.rr.com>
Hello,

I have a server created using LW 4.1.2.  The server calls (read stream nil
stream) and
expects tokens as commands and arguments.

My problem is that it crashes when it receives a #\Backspace character.  I
can't tell if
it is because I am using the wrong type of stream element or what.  I notice
that (read)
in the listener does fine.

I will ask LW support but thought I might check here in case it is (L)user
error : )

sample session:

CL-USER 119 > (comm:open-tcp-stream "localhost" 10244)
#<COMM:SOCKET-STREAM 20415C0C>

CL-USER 120 > (setf server *)
#<COMM:SOCKET-STREAM 20415C0C>

CL-USER 121 > (format server ":start-session ")
NIL

CL-USER 122 > (force-output server)
NIL

CL-USER 123 > (read server)
863895753

CL-USER 124 > (write-char #\Backspace server)
#\Backspace

CL-USER 125 > (force-output server)
NIL

CL-USER 126 > (read-line server)
"Unhandled Exception, Saw character Backspace with syntax type invalid."
NIL

CL-USER 127 > (stream-element-type server)
BASE-CHAR

CL-USER 128 > (typep #\backspace 'base-char)
T

Don't really know what else to check....

Thanks,
Coby

--
(remove #\space "coby . beck @ opentechgroup . com")

From: Kent M Pitman
Subject: Re: read, socket-streams and #\Backspace
Date: 
Message-ID: <sfwae06swm8.fsf@world.std.com>
"Coby Beck" <·····@mercury.bc.ca> writes:

> I have a server created using LW 4.1.2.  The server calls (read
> stream nil stream) and expects tokens as commands and arguments.
> 
> My problem is that it crashes when it receives a #\Backspace
> character.  I can't tell if it is because I am using the wrong type
> of stream element or what.  I notice that (read) in the listener
> does fine.
 
No, the stream type is fine. Type this character sequence to a Lisp
Listener and you will get the same effect:

 ( r e a d ) Control-q Backspace Enter

> I will ask LW support but thought I might check here in case it is
> (L)user error : )

It looks like an LW bug.  It happens in 4.1.20, too.

ANSI CL Figure 2-7 in Section 2.1.4 (Character Syntax Types) says Backspace
is supposed to be a constituent character type.

LWW 4.1.20 seems to get this wrong, but the Franz ACL 6.0 Trial Edition 
I have gets it right.  Here's an easier test case for your bug report:

 (read-from-string (make-string 1 :initial-element #\Backspace))

> sample session:
> 
> CL-USER 119 > (comm:open-tcp-stream "localhost" 10244)
> #<COMM:SOCKET-STREAM 20415C0C>
> 
> CL-USER 120 > (setf server *)
> #<COMM:SOCKET-STREAM 20415C0C>
> 
> CL-USER 121 > (format server ":start-session ")
> NIL
> 
> CL-USER 122 > (force-output server)
> NIL
> 
> CL-USER 123 > (read server)
> 863895753
> 
> CL-USER 124 > (write-char #\Backspace server)
> #\Backspace
> 
> CL-USER 125 > (force-output server)
> NIL
> 
> CL-USER 126 > (read-line server)
> "Unhandled Exception, Saw character Backspace with syntax type invalid."
> NIL
> 
> CL-USER 127 > (stream-element-type server)
> BASE-CHAR
> 
> CL-USER 128 > (typep #\backspace 'base-char)
> T
> 
> Don't really know what else to check....

Comparing to a different kind of stream is always the right thing.

Now, as a separate matter, I am really surprised you're doing READ on
a stream with just a backspace in it.  Are you sure you don't want 
READ-CHAR??  Or is this a stripped down problem from another bug.
(Just a rhetorical question.  No reply required.)
From: Martin Simmons
Subject: Re: read, socket-streams and #\Backspace
Date: 
Message-ID: <1000146439.72418@itn>
"Kent M Pitman" <······@world.std.com> wrote in message
····················@world.std.com...
> "Coby Beck" <·····@mercury.bc.ca> writes:
>
> > I have a server created using LW 4.1.2.  The server calls (read
> > stream nil stream) and expects tokens as commands and arguments.
> >
> > My problem is that it crashes when it receives a #\Backspace
> > character.  I can't tell if it is because I am using the wrong type
> > of stream element or what.  I notice that (read) in the listener
> > does fine.
>
> No, the stream type is fine. Type this character sequence to a Lisp
> Listener and you will get the same effect:
>
>  ( r e a d ) Control-q Backspace Enter
>
> > I will ask LW support but thought I might check here in case it is
> > (L)user error : )
>
> It looks like an LW bug.  It happens in 4.1.20, too.
>
> ANSI CL Figure 2-7 in Section 2.1.4 (Character Syntax Types) says Backspace
> is supposed to be a constituent character type.

True, but doesn't the "invalid" trait make it an error (2.1.4.2 (Constituent
Traits) Figure 2-8)?
--
Martin Simmons, Xanalys Software Tools
······@xanalys.com
rot13 to reply
From: Kent M Pitman
Subject: Re: read, socket-streams and #\Backspace
Date: 
Message-ID: <sfwbskiivge.fsf@world.std.com>
"Martin Simmons" <······@xanalys.com> writes:

> "Kent M Pitman" <······@world.std.com> wrote in message
> ····················@world.std.com...
> > "Coby Beck" <·····@mercury.bc.ca> writes:
> >
> > > I have a server created using LW 4.1.2.  The server calls (read
> > > stream nil stream) and expects tokens as commands and arguments.
> > >
> > > My problem is that it crashes when it receives a #\Backspace
> > > character.  I can't tell if it is because I am using the wrong type
> > > of stream element or what.  I notice that (read) in the listener
> > > does fine.
> >
> > No, the stream type is fine. Type this character sequence to a Lisp
> > Listener and you will get the same effect:
> >
> >  ( r e a d ) Control-q Backspace Enter
> >
> > > I will ask LW support but thought I might check here in case it is
> > > (L)user error : )
> >
> > It looks like an LW bug.  It happens in 4.1.20, too.
> >
> > ANSI CL Figure 2-7 in Section 2.1.4 (Character Syntax Types) says Backspace
> > is supposed to be a constituent character type.
> 
> True, but doesn't the "invalid" trait make it an error (2.1.4.2 (Constituent
> Traits) Figure 2-8)?

Oops!  You know, some little voice in the back of my brain when I was
sending that message said "there is another relevant table" and I peeked
about briefly and didn't see one.  2.1.4.3 confirms your belief.
I stand corrected.  Thanks.

(Btw, this makes it instead a bug in ACL 6.0 Trial Edition, which fails
to signal the error.)