Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site utah-gr.UUCP
Path: utzoo!linus!decvax!wivax!cadmus!harvard!seismo!utah-cs!utah-gr!thomas
From: thomas@utah-gr.UUCP (Spencer W. Thomas)
Newsgroups: net.unix-wizards
Subject: Re: 4.2bsd eof flag in stdio
Message-ID: <1246@utah-gr.UUCP>
Date: Mon, 19-Nov-84 01:41:01 EST
Article-I.D.: utah-gr.1246
Posted: Mon Nov 19 01:41:01 1984
Date-Received: Wed, 21-Nov-84 05:29:16 EST
References: <1697@ucf-cs.UUCP> <1796@sun.uucp> <5867@brl-tgr.ARPA>
Reply-To: thomas@utah-gr.UUCP (Spencer W. Thomas)
Organization: Univ of Utah CS Dept
Lines: 24
Summary: 

In article <5867@brl-tgr.ARPA> gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) writes:
>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?
The problem is if you type 'foo^D' with no newline.  You would expect
that this would terminate input reading, but it does not -- you must
type another ^D to finish it off.
>
>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.
>
This is, of course, a matter of opinion, but all the documentation
states that ^D is the *end-of-file* character.  Perhaps the
documentation (unchanged since my memory) is "buggy"?

>If the 4.2BSD fread() was buggy, it should have been fixed rather
>than introducing a significant incompatibility with other STDIOs.
This bug is in ALL versions of fread (and getchar, and ...) *except*
4.2.

=Spencer