Stdio buffer flushing

[Leslie Mikesell]

In article <13315 at smoke.BRL.MIL> gwyn at smoke.BRL.MIL (Doug Gwyn) writes:
   >>(void)vfprintf(logfile, fmt, ap);
   >>putc('\n', logfile);	/* log messages don't come with \n */
   >>(void)fflush(logfile);
   >>Apparently the putc is performing a flush *before* adding the \n, so
   >>that a concurrent process can write it's entry first.  Is this a
   >>bug or are you not supposed to mix different forms of buffered output?

>All stdio I/O operations are defined in terms of getc() and putc(),
>so clearly "mixing forms" of output is not an issue.  However, there
>is no particular guarantee that an output operation will not cause
>an actual write() at some point, even if you have setbuf()ed and have
>not yet invoked fflush().  Certainly when the buffer is full it will
>be automatically flushed.  While I'm not sure why your implementation
>of vfprintf() (or less likely, putc()) would flush the buffer where
>you say it did, there is no rule that prohibits it from doing so.
>The C standard does not require that no extra buffer flushing occur,
>although it does suggest that it is not intended.

OK, if it's not a bug it's at least "interesting behaviour" that the
timing of the write() depends on whether or not setbuf() has been
called.  Under SysVr3.2 (3B2 & 386), if setbuf() is called, the
putc('\n',...) above causes a write() of the previous buffered contents
(even though the buffer is not full).  Without setbuf(), it doesn't.
This may only occur the first time putc() is called.

Les Mikesell
  les at chinet.chi.il.us