Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!mcgill-vision!mouse
From: mouse@mcgill-vision.UUCP (der Mouse)
Newsgroups: comp.unix.wizards
Subject: Re: Stdio (stderr) buffering question
Message-ID: <1178@mcgill-vision.UUCP>
Date: 22 Jun 88 17:44:23 GMT
References: <16124@brl-adm.ARPA> <8063@brl-smoke.ARPA> <5027@sdcsvax.UCSD.EDU>
Organization: McGill University, Montreal
Lines: 20

In article <5027@sdcsvax.UCSD.EDU>, hutch@net1.ucsd.edu (Jim Hutchison) writes:
> So how many things break if stderr is line buffered?  (Meaning that
> when you get a \n or a full buffer WECF.)

Very little will actually break, but it will make stderr next to
useless for debugging.  It would force the poor programmer to follow
ever fprintf(stderr,...) with fflush(stderr) to make up for it - why
uglify everyone's code for no good reason?

The efficiency argument is quite bogus (for stderr).  Stderr is used
for two things: printing error messages (efficiency irrelevant,
buffering probably acceptable) and printing debugging messages
(efficiency irrelevant, buffering definitely harmful).  There are
exceptions to this general rule (tar cvf - being notable), but they are
few enough that inserting a setbuf or setlinebuf call is no great pain.

					der Mouse

			uucp: mouse@mcgill-vision.uucp
			arpa: mouse@larry.mcrcim.mcgill.edu