[net.unix-wizards] stdio buffering...

gordonl (07/31/82)

We are aware of the stdio/tty buffering problem, but find the
Berkeley solution inadequate.  Too many programs, especially
screen-oriented ones, expect fragments of output to appear on the
screen immediately.  Some, for example, use rawio and 'read' for
character input; when we move these to our 4.1bsd vax they
stop working!

	Our fix to stdio was designed to guarantee transparency
of function while improving performance.  Basically, we buffer output
and flush it through whenever stdio returns control to the user program.
Thus, the output for a 'printf' or 'puts' will go out as one write.

On the bad news side, programs written to do 'putc's see no gain
with our stdio.  However, we felt we could not accept the Berkeley
method as it breaks previously working programs.

	gordon letwin
	microsoft

gwyn@Brl@sri-unix (08/24/82)

From:     Doug Gwyn <gwyn@Brl>
Date:     14 Aug 82 1:13:06-EDT (Sat)
Strange, I use fflush() whenever buffering of output would be a
problem.  This gets the efficiency benefit (especially if you use
setbuf() to buffer stdout) with no hassles.

Perhaps the real problem is, some programmers don't understand how
to use the buffered i/o package correctly.  It really is useful
if you take the trouble to exert proper control over the buffering
strategy when you program.  On the other hand, no automatic buffering
scheme will be appropriate in all cases for people who can't be
bothered to invoke flushing/buffering when required.

scw@ucla-locus@cepu.UUCP (07/23/83)

From:  Steve Woods <cepu!scw@ucla-locus>

    .
    .
    .
	STDOUT=LINE_BUFFERED m4 | adb
Is this reasonable?  Is there a better way?

	Dan Franklin

ARGGGGGGGGGGGGH!!!!!!, There must be a better way, I sort of like the '-u'
myself. I can see it now every ones environmet is 5004 bytes long, remember,
not everyone has a VAX.