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