4.2bsd eof flag in stdio

[jim at ISM780B.UUCP]

>It is obvious from this, that no distinction is made of EOT chars meaning
>anything but the absolute end-of-file on TTY.

Quite wrong.  As you quoted, EOT terminates an input line, and *if that line
is empty*, the return value is zero, and the *zero return value from read*
is interpreted as EOF, not receipt of EOT.  But that is not really relevant
to fread.  What is relevant is that the current call to fread stops when it
encounters EOF; NOWHERE DOES IT SAY THAT FREAD RETURNS ZERO UPON END-OF-FILE.
It doesn't unless an EOF is encountered when fread tries to read its first
byte.  Nowhere does it say that EOF latches, any more than it does for read.
It is the nature of UNIX terminals that you can read past the EOF;
that is why fread behaved as it does, totally consistent with the
documentation.  To quote Bill Shannon,

"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."

But that is exactly what fread should do: return a short record
(as documented; read returns 0, as documented) and go on reading
past the EOF on the next fread (just as read goes on reading beyond
EOF).  Only improperly written programs that erroneously assume that
fread signals EOF with a zero return value (it doesn't;
it isn't documented to) have the "bug".

read is different from fread because it is delimited by newline, so that
EOT at the beginning of a line always causes a zero return, because the
first character of a line must be the first character read (although not
necessarily vice versa); this simply isn't true of fread.
For routines for which it is true, such as fgets or getc, then the return
value can be used to detect EOF.

You cannot show that the SysV fread is wrong by quoting the *read*
documentation, especially without understanding why the two are different.

-- Jim Balter, INTERACTIVE Systems (ima!jim)