On Mon, Jul 27, 2009 at 3:42 PM, Daniel Jacobowitz <drow@false.org> wrote:

On Mon, Jul 27, 2009 at 03:33:08PM +0200, Filip Navara wrote:
> On Mon, Jul 27, 2009 at 3:21 PM, Daniel Jacobowitz<drow@false.org> wrote:
> > On Mon, Jul 27, 2009 at 10:02:04AM +0000, Filip Navara wrote:
> >> On Win32 the setvbuf function requires the last parameter to be size between 2 and INT_MAX bytes, so the calls always failed. Since the whole point of the calls is to set line-buffered mode for the file handle and that's not supported on Win32 anyway, conditionally remove them.
> >
> > Should they be unbuffered where _IOLBF is not supported, then? I
> > assume the line buffering was to make them more useful in event of a
> > crash.
>
> I guess your assumption is correct. I'd be fine with using _IONBF for
> the exec.c part, but setting it for stdout doesn't sound too useful to
> me.

I've found that leaving stdout buffered on Windows is a pain; on Unix
"isatty()" is reliable, but on Windows it breaks down at the
Cygwin/Windows interaction border. So your simulated programs end up
using block output all the time if you have a mingw32 qemu in a Cygwin
terminal, for instance.

I use MinGW-built QEMU in regular command line and MSYS sh and I never had a single problem with the buffering. I can't speak for Cygwin, but if they can't get it right I don't think it's up to QEMU to fix it (heck, checking for a console handle is as easy as "(handle & 3) != 0").

The log files are different story, since for certain types of crashes the last block is lost. Since log files are actually used for debugging problems I acknowledge that keeping the content is important.

Best regards,

Filip Navara