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.