Vladimir Panteleev <> changed:

           What    |Removed                     |Added
             Status|NEW                         |RESOLVED
                 CC|                            |
         Resolution|                            |WONTFIX

--- Comment #3 from Vladimir Panteleev <> 2011-08-23 
20:34:15 PDT ---
The problem comes from mixing usage of text-reading methods (readLine / getch /
etc.) with those reading binary data (read(T)). readLine is conservative when
it comes to consuming newlines; when it thinks there may be more characters
completing the newline after what it's read so far, it sets a flag so future
calls to readLine/getch ignore the first line feed on the stream.

I found it curious that whether or not the stream is seekable controls whether
readLine uses getc/ungetc or the "maybe-linefeed-after-this" boolean flag -
even though in ungetc doesn't actually use any streaming methods, and instead
maintains a separate "unget" buffer. Of course, that also causes problems when
mixing binary and text functions. If the first lines in the test data attached
to this bug report were terminated by UNIX line endings, using a File stream
would have yielded unexpected results as well.

Of course, the bigger problem here is the overall design of A much
better design decision would have been to implement the text-reading methods in
a new class on top of a binary-only Stream class. The new class could then
override the binary reading methods and make them aware of the unget buffer

Since I believe it's generally been decided that (and
std.socketstream correspondingly) is on its path to deprecation in favor of
std.stdio.File and ranges (see e.g. Issue 4025), I think it's safe to mark this
one as WONTFIX.

Also, I just noticed this bug report is from 4 years ago. What am I doing it's
6 AM I should be in bed.

Configure issuemail:
------- You are receiving this mail because: -------

Reply via email to