Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 beta 3/9/83; site desint.UUCP
Path: utzoo!watmath!clyde!bonnie!akgua!sdcsvax!sdcrdcf!trwrb!desint!geoff
From: geoff@desint.UUCP (Geoff Kuenning)
Newsgroups: net.unix-wizards
Subject: Re: 4.2bsd eof flag in stdio
Message-ID: <212@desint.UUCP>
Date: Tue, 13-Nov-84 02:13:04 EST
Article-I.D.: desint.212
Posted: Tue Nov 13 02:13:04 1984
Date-Received: Thu, 15-Nov-84 03:53:38 EST
References: <1697@ucf-cs.UUCP>
Organization: his home computer, Thousand Oaks, CA
Lines: 36

In article <1697@ucf-cs.UUCP> goldfarb@ucf-cs.UUCP (Ben Goldfarb) writes:

>Why did Berkeley change stdio such that typing ^D (or whatever EOF character
>one is using) on stdin causes that stream to reflect eof until a clearerr()
>is done?  Has this been discussed here before?  If so, I apologize for 
>further belaboring the issue.
>
>In any case, what is the correct approach to this problem?

We did this when I was at DEC because that's the way a file behaves, and it
is frequently easier to write a program to read the EOF twice.  For example:

	while ((ch = getchar ()) != EOF)
	    switch (ch)
		{
		case '\\':
		    switch (ch = getchar ())
			{
			case EOF:
			    break;
			}
		    break;
		}

Here, reading the EOF twice is a convenient way to handle the loop exit.
(Yes, there are other ways, notably using a goto.  But in more complex code
this approach may be the cleanest).  I never like assuming that I can unget
an EOF character (although it works on some systems).

One can also make a persuasive argument for the advantages of the other
approach, but I prefer this way because of consistency.
-- 

	Geoff Kuenning
	First Systems Corporation
	...!ihnp4!trwrb!desint!geoff