stdio buffering considered harmful

[trt at rti-sel.UUCP]

The stdout buffering discussion has occurred at least twice before on Usenet.
Some blame stdio for being insufficiently clever,
some blame programmers for not defending against stdio's cleverness,
I blame Dennis Ritchie for not taking the buffering problem seriously.
(He once said he never wanted people to use the 'setbuf' hack,
that buffering in stdio should be transparent.  Alas, it is not.)

HOW TO LIVE WITH STDIO BUFFERING
Programming 'correctly' in the presence of stdio buffering
is a bit hard to define, but you probably need to put an fflush(stdout)
before each of the following system calls:
	read, pause (also 'sleep'), fork, exec[lv], kill, wait, ioctl ('stty')
Oddly, exit(II) is OK since it "knows" about stdio.  Oh yes, do not use lseek.
If you are debugging, put an fflush in just before it core dumps.
Oh, and do an fflush before a long running computation.
Do you need to fflush before a 'system'?  It gets awful, doesn't it.

I have found that portability and efficiency are well served
by turning on stdio buffering at the very beginning of main():
	setbuf(stdout, BUFFERED_STDIO);
That means I have to put fflush()es all over the place
so the program works, but that is OK because if I do not
the program will not work in the presence of clever stdio systems, anyway.

For portability, the following are handy (but not perfect):
	#ifndef	BUFFERED_STDIO
	#define	BUFFERED_STDIO	(char *)malloc((unsigned)BUFSIZ)
	#endif
	#ifndef	UNBUFFERED_STDIO
	#define	UNBUFFERED_STDIO (char *)NULL
	#endif
Tom Truscott
P.S.  I have an old article on what is wrong with stdio buffering
and how it was fixed at Duke.  Anyone want it re-submitted?