#573 read over socket confuses CR/LF

[Anonymous]

When reading over a socket, clisp reads a carriage-return/line-feed character _pair_ as a #\Newline character (single). After returning the #\Newline, (listen mysock) still reports T even when there is nothing left to return. This does not happen if reading from a string directly.

;;set up
(setq foo (concatenate 'string "any thing here" (string (code-char 13)) (string (code-char 10))))
;; then,
(with-input-from-string (is gak) (loop while (listen is) collect (read-char is)))
;; reports correctly, but if you send gak over a socket and read from the socket, it will read a #\Newline (skipping over the #\Return) but (listen sock) will report T
;; with the result that any read hangs waiting for input which is not there although listen indicated there was something.

[Sam Steingold]

This bug report is now marked as "pending"/"invalid".
This means that we think that the problem you report is not a problem with CLISP.
Unless you - the reporter - act within 2 weeks, the bug will be permanently closed.
Sorry about the inconvenience - we hope your silence means that you agree that this is not a bug in CLISP.

[Sam Steingold]

1. reading from a socket CRLF --> #\Newline: http://clisp.sourceforge.net/impnotes/clhs-newline.html
2. listen returning T and read-char hanging: cannot reproduce, please give detailed instructions.
when one clisp writes foo to a socket, the other reads (#\a #\n #\y #\Space #\t #\h #\i #\n #\g #\Space #\h #\e #\r #\e #\Newline) from it, as expected.

[Anonymous]

Yes, it seems the problem is that CLISP reads the CRLF pair as #\Newline, but somehow listen doesn't get the message and reports that there is more to be read. But attempting to read then hangs because both the #\Return and #\Linefeed have been consumed. At least, that's my theory.

To replicate (w/ GNU CLISP 2.44.1 Ubuntu 10.04)
[23]> (setf gak (concatenate 'string "four" (string #\Return) (string #\Linefeed)))
"four
"
[25]> (with-input-from-string (is gak) (loop while (listen is) collect (read-char is)))
(#\f #\o #\u #\r #\Return #\Newline)
[26]>

So things are OK so far, at least with reading from the string.

Create socket to another CLISP process. Send the string, gak, to the client.
[28]> (format sockstream* "~A" gak)
NIL
[29]>

On the client, attempting the similar read hangs:
[5]> (loop while (listen sockstream*) collect (read-char sockstream*))
^C
*** - Ctrl-C: User break
The following restarts are available:
ABORT :R1 Abort main loop
Break 1 [6]>

And if we try again with a more cautious reading gives the following but (listen sockstream) still reports T but hangs when read-char
[14]> (loop for i below 5 collect (read-char sockstream*))
(#\f #\o #\u #\r #\Newline)
[15]> (listen sockstream*)
T
[16]> (read-char sockstream*)
^C
*** - Ctrl-C: User break
The following restarts are available:
ABORT :R1 Abort main loop
Break 1 [17]>

Using SBCL as the client (but still CLISP as the server), I can drain the socket getting the list (#\f #\o #\u #\r #\Return #\Newline)

I apologize if this is not a CLISP problem, but instead a problem with my sockets implementation. I'm using CLOCC (with both CLISP and SBCL).

[Sam Steingold]

your code works just fine for me with the current clisp.
it is quite possible that the bug you are reporting have been fixed since 2.44 was released a few years ago.
please upgrade to clisp 2.49.

[Anonymous]

Thanks! It works for me with 2.49. Any idea why Ubuntu bundles such an old release in 10.04?

[Sam Steingold]

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=504514
https://bugs.launchpad.net/ubuntu/+source/clisp/+bug/603313