Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site mulga.OZ
Path: utzoo!linus!decvax!mulga!kre
From: kre@mulga.OZ (Robert Elz)
Newsgroups: net.unix-wizards
Subject: Re: 4.2bsd eof flag in stdio
Message-ID: <552@mulga.OZ>
Date: Thu, 22-Nov-84 18:38:48 EST
Article-I.D.: mulga.552
Posted: Thu Nov 22 18:38:48 1984
Date-Received: Sat, 24-Nov-84 05:41:42 EST
References: <1697@ucf-cs.UUCP> <1796@sun.uucp> <5867@brl-tgr.ARPA> <1246@utah-gr.UUCP> <5901@brl-tgr.ARPA>
Reply-To: kre@mulga.OZ (Robert Elz)
Organization: Comp Sci, Melbourne Uni, Australia
Lines: 59

From Doug Gwyn (in the last referenced article):
| 
| > 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"?
| 
| Yup.  Kernighan & Pike got it right in their book.
| 

Rarely does anyone play into my hands quite no nicely.  Now that
we have K&P cited as the absolute authority on this issue, I
will proceed to quote from page 204.

	   Structurally, readslow is identical to cat except that
	it loops instead of quitting when it encounters the current
	end of the input.  It has to use low-leval I/O because the
	standard library routines continue to report EOF after the
	first end of file.

This immediately precedes the listing of the "readslow" program,
which is the authorised version of "tail -f" according to the
gosple of St Pike.

I'm not sure which particular version of "the standard library
routines" they were referring to - this was written before 4.2
was released.  I always assumed that V8 had fixed the bug as
well, but I was (not too long ago) told that this was not so.
Would you care to clarify rob?

The above inclusion (from pervious articles) is, of course,
completely irrelevant to the original discussion under this
subject line.  It makes absolutely no difference what ^D from
the terminal really does, or does not do.  What is important,
is that stdio returns EOF from a getchar(), fread(), scanf()
or whatever.  Not a zero length read, EOF.  (And as EOF is
actually returned to mean a few other things, there is this
nifty macro "feof" that you can use to verify that this
really was "end of file").

I don't think its at all unreasonable for "end of file" to
be a "sticky" condition,
	Kernighan & Pike got it right in their book.

Finally, it seems that their are two vocal groups of "anti-4.2"
people out there.  There seems to be one group that complains
bitterly about all the "bugs" berkeley introduced, and all the
things that they "broke", and a second group that complains
bitterly about all the "bugs" left in the code, and the things
that weren't done.  What's most amazing is that it seems often
that the most vocal members of each group are the same people.

Rather a double standard - they didn't fix the bugs that make
my life difficult, 'cause I have to fix them to run their code
on my hardware, but they did fix all the bugs I was relying on ...

Can we end this useless discussion now, and allow it to die
until someone else new "discovers" it again (in about a week)?

Robert Elz					decvax!mulga!kre