Bug 387 – When EOF of din is reached, a line of output is lost

The following program should wait for an EOF from the standard input, and then output two lines of text: ---------- import std.cstream; import std.stdio; void main() { while (din.getc != char.init) {} writefln("Line 1"); writefln("Line 2"); } ---------- In fact, only "Line 2" gets printed. I've experimented with writef, dout.writefln, dout.writef, dout.write(char), dout.writeString and dout.writeLine, all with the same results. The output is also the same if the writefln statements are consolidated into one: writefln("Line 1\nLine 2"); The bug also bites if din.readLine is used: while (din.readLine != "") {} Changing either or both lines of output to go to stderr also makes no difference. Mysteriously, if either input or output is redirected, or the program is at either end of a pipe, then the bug doesn't show. There's no obvious workaround. Calling din.flush() or dout.flush() at any point makes no difference. While you could add a dummy line of output, this would both break the program when the bug is fixed and break it with the aforementioned redirection and piping. This is likely to block people trying to write various Unix-style tools.

Works for me. >dmd -run issue387.d ^Z Line 1 Line 2 > Window XP, DMD 0.167

Works for me too ... c:\temp>type test.d import std.cstream; import std.stdio; void main() { while (din.getc != char.init) {} writefln("Line 1"); writefln("Line 2"); } c:\temp>bud test Path and Version : y:\util\bud.exe v3.03(2370) built on Wed Sep 20 16:16:41 2006 c:\temp>test <test.d Line 1 Line 2 c:\temp>

So it works on WinXP. It's 98SE I'm having trouble on. (In reply to comment #2) > c:\temp>test <test.d > Line 1 > Line 2 My point is that it's when _not_ redirecting that the problem shows up. For the record, what OS version are you on, Derek?

Alas, it's a bug with the OS. I've tried the C stdio API (both DM and Borland implementations) and the Windows file I/O API with the same effect. And I'm still lost for a workaround. I can't even find any stream state information that can have anything to do with the problem. But at least something that can be done now is to find out on which Windows versions the bug occurs. We have that it works on XP and fails on 98SE. This leaves 95, 98, ME, 2000 and Server 2003 to check if I haven't missed any.

Stewart Gordons said: > But at least something that can be done now is to find out on which Windows > versions the bug occurs. We have that it works on XP and fails on 98SE. This > leaves 95, 98, ME, 2000 and Server 2003 to check if I haven't missed any. I think you missed previous NT versions. Anyway, it works fine on Win2000: -------------------------- D:\Temp>type test.d import std.cstream; import std.stdio; void main() { while (din.getc != char.init) {} writefln("Line 1"); writefln("Line 2"); } D:\Temp>dmd test.d d:\d\dmd\bin\..\..\dm\bin\link.exe test,,,user32+kernel32/noi; D:\Temp>test.exe ^Z Line 1 Line 2 D:\Temp>test.exe < test.d Line 1 Line 2 D:\Temp>ver Microsoft Windows 2000 [Version 5.00.2195] D:\Temp> --------------------------

Stewart Gordon wrote: > I know somebody who was, until a year or three ago, still doing > everything in MS-DOS. I know someone who was, until a day or six ago, still doing everything in MS-DOS. With about 4MB RAM. At 12 Mhz (IIRC). Of course, "everything" here means "everything pc-related he does" which in turn means "run one specific program". All he did with it was use it as a terminal that connected (over an old-fashioned modem) to a special-purpose feeding computer on the farm he runs. Some people use old stuff because it works and they don't need more than it provides. Especially if they never connect to the net (so no security updates, latest-browser-features, etc. required). That said though, he has since upgraded... to Windows 98 ;) He still only runs one program that would run fine in DOS though. But now he runs it at 1 GHz.

(In reply to comment #4) > But at least something that can be done now is to find out on which Windows > versions the bug occurs. Works Vista RC1.

We've got that it works on 2000, XP and Vista RC1. And that it fails on 98SE. this leaves 95, 98FE, NT 4, ME and Server 2003. My guess would be that the bug is in 95 and 98FE as well as 98SE, and in Server 2003 as well as the others from 2000 up. But what about NT 4 and ME? I can't guess whether these have the bug at the moment. (OK, so there's also Win32s and NT 3.x - but do we really need to worry about these?)

It's been established that it's a bug in some versions of Windows, not in Phobos or any of the C libraries it uses. Thinking about it now, I don't suppose it's worth adding a workaround layer. For all I know, the versions of Windows that suffer the bug are probably no longer supported. And those who want this compatibility anyway can use my library.... http://pr.stewartsplace.org.uk/d/sutil/ What are we going to do with this bug report now?

As dlang-Win9x support will be stopped soon, close it? (In reply to comment #9) > It's been established that it's a bug in some versions of Windows, not in > Phobos or any of the C libraries it uses. > > Thinking about it now, I don't suppose it's worth adding a workaround layer. > For all I know, the versions of Windows that suffer the bug are probably no > longer supported. And those who want this compatibility anyway can use my > library.... > http://pr.stewartsplace.org.uk/d/sutil/ > > What are we going to do with this bug report now?

(In reply to comment #10) > As dlang-Win9x support will be stopped soon, close it? Validated on Windows 7 x86_64 - works fine.

Closing as invalid as the problem appears to be caused by an OS bug in versions of Windows that are no longer supported.