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!watmath!clyde!bonnie!akgua!mcnc!decvax!wivax!cadmus!harvard!seismo!brl-tgr!gwyn From: gwyn@brl-tgr.ARPA (Doug Gwyn ) Newsgroups: net.unix-wizards Subject: Re: 4.2bsd eof flag in stdio Message-ID: <5867@brl-tgr.ARPA> Date: Sat, 17-Nov-84 22:43:49 EST Article-I.D.: brl-tgr.5867 Posted: Sat Nov 17 22:43:49 1984 Date-Received: Tue, 20-Nov-84 02:41:22 EST References: <1697@ucf-cs.UUCP> <1796@sun.uucp> Organization: Ballistic Research Lab Lines: 21 > 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.