Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!usc!apple!snorkelwacker.mit.edu!bloom-picayune.mit.edu!news
From: scs@adam.mit.edu (Steve Summit)
Newsgroups: comp.lang.c
Subject: Re: Why stderr should be unbuffered
Message-ID: <1990Dec8.004640.22801@athena.mit.edu>
Date: 8 Dec 90 00:46:40 GMT
References: <1990Dec6.055052.10616@athena.mit.edu>
Sender: news@athena.mit.edu (News system)
Reply-To: scs@adam.mit.edu
Organization: Thermal Technologies, Inc.
Lines: 28

In article <1990Dec6.055052.10616@athena.mit.edu>, I wrote:
>Once upon a time, errno was always unbuffered, and stdout was
>always buffered.

(Of course, I was trying to say "stderr was always unbuffered.")

Mark Brader has pointed out that this was never actually true
(among other things, stdio has never fully buffered stdout to a
terminal).  I wasn't trying to be definitive about stdio's
history, and this is probably not the time or the place to embark
upon Yet Another C/Unix archeological expotition.  (It's probably
good FAQ list fodder, though; perhaps for the one in comp.unix.)

I'll stand by my main points, which were that line buffering
(especially its implicit fflush of stdout when input is
requested, which I didn't mention) is dubious, and that any
buffering of stderr is a mistake.  Of course, at this point
complaining about stderr buffering is tilting at windmills,
because X3.159 allows stderr to be line buffered, so one should
be sure to end all error messages in \n (or call fflush(stderr))
whether one likes it or not.  (By the way, I'm not castigating
line buffering's output fflush upon input because it doesn't do
the right thing, which it in fact does, but simply because it's
an ugly special case.  I just noticed that X3.159 doesn't mention
it, and I'll not complain.)

                                            Steve Summit
                                            scs@adam.mit.edu