4.2bsd eof flag in stdio

[Doug Gwyn <gwyn>]

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

fread() returns 0 if there are 0 characters left in the terminal
input queue when the ^D is typed.  What would you have it do?

Contrary to popular misconception, ^D is NOT an "EOF" character;
rather, it marks a delimiter for input canonicalization.  If all
previous input has been consumed and a ^D is typed, then read()
returns a count of 0.  This is often interpreted as EOF.  If there
is some uncanonicalized input and ^D is typed, it acts much like
NEWLINE except of course no \n is appended.

If the 4.2BSD fread() was buggy, it should have been fixed rather
than introducing a significant incompatibility with other STDIOs.