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!linus!decvax!decwrl!sun!shannon
From: shannon@sun.uucp (Bill Shannon)
Newsgroups: net.unix-wizards
Subject: Re: 4.2bsd eof flag in stdio
Message-ID: <1805@sun.uucp>
Date: Fri, 23-Nov-84 19:39:07 EST
Article-I.D.: sun.1805
Posted: Fri Nov 23 19:39:07 1984
Date-Received: Sat, 24-Nov-84 05:58:52 EST
References: <1697@ucf-cs.UUCP> <1796@sun.uucp> <5867@brl-tgr.ARPA> <1797@sun.uucp> <5991@brl-tgr.ARPA>
Organization: Sun Microsystems, Inc.
Lines: 36

> Thanks for the example, Bill.  I guess we disagree about what is
> expected here.  The "EOFish" nature of the input is reflected in
> fread()'s short return count; as expected the 0-length read forces
> fread() to return prematurely.  I see no reason for it to "stick"
> at EOF, though.  The programmer certainly can tell that he is at
> EOF from the short count.  Continuing to read the stream is a
> programming error (that happens to work on "ordinary" files,
> unless they are being dynamically appended to), and more than a bit
> sloppy besides (just like the internals of most UNIX utilities).

If you think of fread as the stdio equivalent of read, and you are
prepared to handle input from a terminal, you will not think of a
short return count as cause for alarm.  Certainly the manual page
gave you no reason to think otherwise.

Also, the manual said fread would return NULL on EOF.  I've clearly
presented an example where it did not return NULL on EOF.  We
considered that a bug, in the manual or in the code, and we chose the
code.  The System V Release 2 manual page for fread has been rewritten
so that it corresponds to what the (non-4.2) code actually does.

This is just another example of the inconsistencies between the UNIX
manuals and the code.  One group chose to fix the code ("people have
been programming according to the manual") while another chose to
fix the manual ("no one reads the manuals anyway, the CODE defines
UNIX").

> I see the argument for the other interpretation; I just don't
> agree with it.

The only good argument against the change was compatibility.  That
may be a strong enough reason to change it back, now that AT&T has
clarified the operation of fread.

					Bill Shannon
					Sun Microsystems