Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA
Path: utzoo!linus!philabs!cmcl2!seismo!brl-tgr!gwyn
From: gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>)
Newsgroups: net.unix-wizards
Subject: Re:  Re:  4.2bsd eof flag in stdio
Message-ID: <5950@brl-tgr.ARPA>
Date: Tue, 20-Nov-84 13:48:25 EST
Article-I.D.: brl-tgr.5950
Posted: Tue Nov 20 13:48:25 1984
Date-Received: Thu, 22-Nov-84 06:27:40 EST
References: <5936@brl-tgr.ARPA>
Organization: Ballistic Research Lab
Lines: 31

[The actual manual entries were somewhat different and clearer.]

This is not the same as saying that EOT "means" EOF.  Only in certain
contexts does it have that effect, as the TERMIO(7) manual entry says.

> What this implies is the zero return from TTY reads are END-OF-FILE
> and should be treated as such.  It is possible to continue reading
> past end of file on some devices such as TTY and Magtape, but that
> doesn't mean you shouldn't handle EOF properly.

Agreed.

> Fread states
> 	Fread stops appending bytes if an end-of-file or error
> 	condition occurs.

And so it does!  But this is on that call, not necessarily on future
calls.  This feature works as advertised on UNIX System V Release 2.0.

> Ferror states
> 	Feof returns non-zero when EOF has previously been detected
> 	reading the named input stream.
> 	Clearerr resets the error indicator and EOF indicator to zero.

Again, this is the way it does work.  The EOF is "latched" until
cleared, but fread() can read past EOF if there is data there.

I'm all for bugs being fixed, if they are really bugs and not just
different ideas about what should be happening.  Perhaps 4.2BSD and
UNIX System V now agree about EOF behavior; that would be a pleasant
change.