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!linus!decvax!genrad!mit-eddie!godot!harvard!seismo!brl-tgr!gwyn
From: gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>)
Newsgroups: net.unix-wizards
Subject: Re: 4.2bsd eof flag in stdio
Message-ID: <5991@brl-tgr.ARPA>
Date: Wed, 21-Nov-84 10:09:06 EST
Article-I.D.: brl-tgr.5991
Posted: Wed Nov 21 10:09:06 1984
Date-Received: Fri, 23-Nov-84 03:08:35 EST
References: <1697@ucf-cs.UUCP> <1796@sun.uucp> <5867@brl-tgr.ARPA> <1797@sun.uucp>
Organization: Ballistic Research Lab
Lines: 37

> #include <stdio.h>
> 
> char	buf[256];
> 
> main()
> {
> 	register int n;
> 
> 	while (n = fread(buf, 1, sizeof buf, stdin))
> 		fwrite(buf, 1, n, stdout);
> 	printf("got EOF\n");
> }
> 
> Run it and type (e.g.):
> 
> testing 1 2 3
> ^D
> another test
> 
> Where ^D is your EOT character.  If the program terminates
> when you type ^D then your stdio works properly.  The 4.1
> version of stdio would "eat" the ^D and echo the first and
> third lines.  It would only terminate if you typed ^D twice
> in a row.

Thanks for the example, Bill.  I guess we disagree about what is
expected here.  The "EOFish" nature of the input is reflected in
fread()'s short return count; as expected the 0-length read forces
fread() to return prematurely.  I see no reason for it to "stick"
at EOF, though.  The programmer certainly can tell that he is at
EOF from the short count.  Continuing to read the stream is a
programming error (that happens to work on "ordinary" files,
unless they are being dynamically appended to), and more than a bit
sloppy besides (just like the internals of most UNIX utilities).

I see the argument for the other interpretation; I just don't
agree with it.