[Issue 1643] New: SocketStream.readLine not processing \r\n properly

[d-bugmail at puremagic.com]

http://d.puremagic.com/issues/show_bug.cgi?id=1643

           Summary: SocketStream.readLine not processing \r\n properly
           Product: D
           Version: 1.020
          Platform: PC
        OS/Version: Windows
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Phobos
        AssignedTo: bugzilla at digitalmars.com
        ReportedBy: daniel.keep+d.puremagic.com at gmail.com


A new user on the #d IRC channel demonstrated a program that works if the data
being read is from a local file, but fails if it is read from a SocketStream.

The data is a message in the following format (listed as a string literal):

"STARTFILES\r\n"
"logs/gamestat.txt\r\n"
"\x00\x00\x00\xa8"
"In-Game Statistics\n"
...

The program uses a stream.readLine loop to look for the filename.  The
SocketStream correctly reads the first line in its entirety.  However, the
SocketStream reads the second line as "logs/gamestat.txt\r" leaving the
following "\n" in the stream.  This means that the four-byte big-endian number
is read incorrectly as "\x10\x00\x00\x00".  This problem DOES NOT occur if the
contents of this message are dumped to disk and read back via a BufferedFile.

If it is relevant, I have noticed that the first line is sent in one chunk from
the server, whilst the next several lines are all sent together.  That is, the
data arrives at the client as:

"STARTFILES\r\n",
"logs/gamestat.txt\r\n\x00\x00\x00\xa8In-Game Statistics\n..."

I believe the problem may lie in std.stream.Stream where readLine treats
seekable streams differently to non-seekable streams.  It could be that prevCr
is not being maintained correctly.

I will attach the source for the program and a sample message dump presently. 
The source is minimal, although a bit messy as it contains the code to dump the
message and read it from disk commented out.


--