Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!umcp-cs!chris
From: chris@umcp-cs.UUCP (Chris Torek)
Newsgroups: net.unix
Subject: Re: why is fprintf(stderr,) slow?
Message-ID: <3201@umcp-cs.UUCP>
Date: Sat, 30-Aug-86 08:57:02 EDT
Article-I.D.: umcp-cs.3201
Posted: Sat Aug 30 08:57:02 1986
Date-Received: Sat, 30-Aug-86 21:32:37 EDT
References: <633@hropus.UUCP> <1480@poseidon.UUCP> <7074@utzoo.UUCP> <338@chronon.chronon.UUCP>
Reply-To: chris@umcp-cs.UUCP (Chris Torek)
Organization: University of Maryland, Dept. of Computer Sci.
Lines: 27

In article <338@chronon.chronon.UUCP> eric@chronon.UUCP (Eric Black) writes:
>Of course, the reason that [stderr printfs use one system call]
>per character is to make sure that the error output in fact gets
>out....  On BSD systems, at least, you can change this with the
>setlinebuf(3S) call, to make stderr use buffering. ... On non-BSD
>systems you're stuck, as far as I know.

Not stuck: there is still setbuf(3S).  A fair fraction of my programs
begin with

	char	serrbuf[BUFSIZ];	/* buffer for stderr */

	main(...)
	{

		setbuf(stderr, serrbuf);

Further calls to fprintf(stderr) are immediately followed either
by exit(code), which flushes all stdio buffers, or an explicit
fflush(stderr).  It is possible to lose error output in some cases;
these I simply put up with, for a simple stack trace tends to
pinpoint them immediately anyway, and even adb prints readable
stack traces (so long as you have symbols!).
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1516)
UUCP:	seismo!umcp-cs!chris
CSNet:	chris@umcp-cs		ARPA:	chris@mimsy.umd.edu