mike@thor.acc.stolaf.edu (Mike Haertel) (05/07/89)
After EOF is returned for the first time, Berkeley stdio functions
will not attempt to read further input if the user tries, but will
instead continue returning EOF.
In Ritchie stdio (v7, System V) subsequent calls to stdio functions
will attempt further reads, and return EOF only if the further reads
also return EOF.
I'm curious which behavior people prefer. The Berkeley behavior
is more convenient for a certain class of lazy programmer, and the
Ritchie behavior is more similar to the underlying Unix calls.
The May 13 1988 dpANS merely says "If the stream is at end-of-file,
the end-of-file indicator for the stream is set and fgetc returns
EOF." It doesn't appear to say anything about the behavior of
subsequent calls.
--
Mike Haertel <mike@stolaf.edu>
main() ??< printf("hello, world??/n"); ??>gwyn@smoke.BRL.MIL (Doug Gwyn) (05/08/89)
In article <2017@thor.acc.stolaf.edu> mike@thor.acc.stolaf.edu (Mike Haertel) writes: >After EOF is returned for the first time, Berkeley stdio functions >will not attempt to read further input if the user tries, but will >instead continue returning EOF. Yeah, we went all over this many moons ago. Sticky EOF was introduced at one point by Bill Shannon. It's not considered proper behavior and should have been removed by now. (Chris Torek should be able to tell us if it was.)
chris@mimsy.UUCP (Chris Torek) (05/08/89)
In article <10229@smoke.BRL.MIL> gwyn@smoke.BRL.MIL (Doug Gwyn) writes: >... Sticky EOF was introduced at one point by Bill Shannon. It's >not considered proper behavior and should have been removed by now. >(Chris Torek should be able to tell us if it was.) It has not. I will think about it. . . . (I need to get some work done on that. So why am I reading news instead? :-/ ) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris