Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!umd5!cvl!elsie!ado
From: ado@elsie.UUCP (Arthur David Olson)
Newsgroups: comp.sys.ibm.pc
Subject: Re: Turbo C 1.5 setbuf(stderr bug
Message-ID: <8018@elsie.UUCP>
Date: 22 Feb 88 19:17:38 GMT
References: <8015@elsie.UUCP> <3433@killer.UUCP>
Organization: NIH-LEC, Bethesda, MD
Lines: 31

In an earlier article I wrote of a "Turbo C 1.5 setbuf(stderr bug":
< Repeat-By:
< 	Compiling and running this source
< 		#include "stdio.h"
< 		main()
< 		{
< 			static char	buf[BUFSIZ];
< 			setbuf(stderr, buf);
< 			(void) fprintf(stderr, "byebye\n");
< 			return 0;
< 		}
< 	and noting the lack of output.

In article <3433@killer.UUCP>, richardh@killer.UUCP (Richard Hargrove) writes:
< In article <8015@elsie.UUCP>, ado@elsie.UUCP (Arthur David Olson) writes:
< < [ code example purporting to demonstrate how calling setbuf() does not
< <   cause stderr to actually become buffered ]
< 
< . . .with stderr [s]ince the line-buffering flag is not set, the call to
< setbuf() causes it to go from being unbuffered to full-buffered.
< Full-buffering means that the buffer contents are output only when the
< buffer has been filled, which your example fails to do. Until the buffer
< is filled, only an explicit call to fflush() will cause the contents of the
< buffer to be output. . .

Regardless of buffering, the contents of the buffer should be output when
the program exits.  And yet no output appears when I compile and run the
source in my original article.  That's the bug--not whether the setbuf call
causes "stderr to actually become buffered."
-- 
ado@vax2.nlm.nih.gov		ADO, VAX, and NIH are Ampex and DEC trademarks