http://d.puremagic.com/issues/show_bug.cgi?id=1643
Vladimir Panteleev <thecybersha...@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |thecybersha...@gmail.com Resolution| |WONTFIX --- Comment #3 from Vladimir Panteleev <thecybersha...@gmail.com> 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 std.stream. 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 etc. Since I believe it's generally been decided that std.stream (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: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------