4.2bsd eof flag in stdio

[Geoff Kuenning]

In article <6059 at brl-tgr.ARPA> gwyn at brl-tgr.ARPA (Doug Gwyn <gwyn>) writes:

>Geoff, I think you missed the point:  ^D (or whatever) from a terminal
>DOES act like EOF if there is nothing between the previous delimiter
>and this one, since read() will return a count of 0 on that record.
>But I have made good use of the more general behavior of ^D in forcing
>non-newline terminated input to the reading process.

No, I didn't miss the point.  I happen to think that the stdio package
should not embed features of UN*X into its assumptions about operating
systems.  There are lots more operating systems with "hard" EOF's than with
soft ones.  If you want to make use of the general behavior of ^D, write your
program to either use clearerr() or use UNIX I/O.

>The only reason repeated reading of an ordinary (disk) file keeps
>returning 0 bytes (NOT "EOF"; there is no such thing in UNIX) is
>that the file size is static.  If the file is being appended to by
>some other process, then continued reading should return data AFTER
>the original "end of file".  The same applies to magtape and terminals.
>This is not only reasonable, it is quite useful.

As to UNIX having EOF, try looking in read(2).  In any case stdio is not UNIX,
and grepping stdio.h for EOF will succeed.  The features you talk to about
(simultaneous read and write, for example) are not available on all OS's.

>I much prefer the thoughtful design of UNIX over the attempts to make
>it look "safe and ordinary".

Good, then use read(2) and write(2).  Stdio is explicitly a compatibility
package.  As such, it _s_h_o_u_l_d be safe and ordinary.

>Whatever program you had that required two successive 0-length reads
>("EOF" indication, by convention) to detect end of input was simply
>WRONG.  (Some old-time Pascal programmers may recognize the problem.)
>Instead of trying to change UNIX by reducing its generality, why not
>fix the erroneous program.  There is no excuse for such sloppiness.

I can do without the snottiness, Doug.  I mentioned in my original posting
that I had already fixed the bug.  My point was that an inconsistency in the
way stdio (_n_o_t UNIX) is implemented caused the program to behave strangely
only when reading from a terminal.

It is unfortunate that this bug stayed in the system for so long that some
people mistook it for a feature.  But that doesn't mean we shouldn't fix it.
-- 

	Geoff Kuenning
	...!ihnp4!trwrb!desint!geoff