why is fprintf(stderr,) slow?

Chris Torek chris at umcp-cs.UUCP
Sat Aug 30 22:57:02 AEST 1986


In article <338 at chronon.chronon.UUCP> eric at 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 at umcp-cs		ARPA:	chris at mimsy.umd.edu



More information about the Comp.unix mailing list