Closed GoogleCodeExporter closed 9 years ago
stderr is not buffered by default on any system that I know. fflush(stderr)
should be unnecessary. Are you doing something unusual in your setup, perhaps?
Or does cygwin? I don't see any mention of it on a quick web search.
Anyway, no harm in adding it, I suppose. Feel free to draw up a patch.
Original comment by csilv...@gmail.com
on 20 May 2011 at 6:15
I've had a bit of a dig, and it turns out that the rxvt terminal emulator that
ships with Cygwin buffers stderr. The reason for this seems to be that rxvt
needs a pty I/O layer that simply doesn't exist on Windows, so it's emulated
with pipes, which introduces the buffering. Given there's no harm adding it,
I'll draw up a patch to work around this. Thanks.
Original comment by alastair.maw
on 31 May 2011 at 9:34
I just released a new version of gflags, and decided not to fix this for that.
stderr is standardized to flush, and I think it's just confusing to add code to
flush it anyway. Presumably cygwin/rxvt users are used to dealing with
problems of this sort?
You're right it's just one line of code, and easy to fix, so I can still be
convinced to do it. :-) I'm leaving the bug open.
Original comment by csilv...@gmail.com
on 30 Jul 2011 at 2:50
} stderr is standardized to flush, and I think it's just confusing to add code
to flush it anyway.
Wouldn't it be clear enough if you simply comment the code properly?
// flush stderr before exiting as at least cygwin/rxvt buffers stderr
fflush (stderr);
This would make your library more reliable and such commented line of code
couldn't be confusing to anyone who is digging into the code of it.
Original comment by andreas....@gmail.com
on 11 Aug 2011 at 4:47
OK, I'm convinced. :-) It'll be in the next release.
Original comment by csilv...@gmail.com
on 26 Aug 2011 at 12:00
This should be fixed in gflags 1.7, just released
Original comment by csilv...@gmail.com
on 21 Dec 2011 at 4:26
Original issue reported on code.google.com by
alastair.maw
on 20 May 2011 at 1:20