Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84 SMI; site sun.uucp
Path: utzoo!watmath!clyde!bonnie!akgua!sdcsvax!dcdwest!ittvax!decvax!decwrl!sun!shannon
From: shannon@sun.uucp (Bill Shannon)
Newsgroups: net.unix-wizards
Subject: Re: 4.2bsd eof flag in stdio
Message-ID: <1796@sun.uucp>
Date: Fri, 16-Nov-84 04:49:36 EST
Article-I.D.: sun.1796
Posted: Fri Nov 16 04:49:36 1984
Date-Received: Sun, 18-Nov-84 04:37:16 EST
References: <1697@ucf-cs.UUCP>
Organization: Sun Microsystems, Inc.
Lines: 28

Ben Goldfarb writes,
> Why did Berkeley change stdio such that typing ^D (or whatever EOF character
> one is using) on stdin causes that stream to reflect eof until a clearerr()
> is done?  Has this been discussed here before?  If so, I apologize for 
> further belaboring the issue.
> 
> In any case, what is the correct approach to this problem?  Obviously, we
> can't expect the authors of programs that have been distributed with UNIX
> since V7 to have provided for Berkeley's change; as it stands I've found
> that addbib and learn are both broken because of the continual EOF.  So I
> patched
> 		if (feof(stdin))
> 			clearerr(stdin);
> into both programs.  I'm sure more are affected.  Alternatively, I could have
> "fixed" stdio, but how many Berkeley programs make use of this "feature?"
> I'd appreciate some net wisdom on the subject.  

The change was made by Sun and bought back by Berkeley.  I believe this
has been discussed on the net before.  The change actually fixes another
bug.  The bug was that without this change programs using fread on terminals
would never report an EOF condition to the user because internally fread
would just swallow the EOF and return a short record and the next fread
would go on reading past the EOF.  We actually ran into this bug in some
existing program, I forget which one.  Unfortunately, not all the programs
which depended on the old behaviour were fixed.

					Bill Shannon
					Sun Microsystems, Inc.