4.2bsd eof flag in stdio

[Kenneth Almquist]

>>If we may believe Bill Shannon, the whole issue arose because nobody
>>could figure out how to make a straightforward change to fread.
>
>Bill said quite explicitly that the change arose because they wanted to make
>the behavior of fread consistent.

That's what I said he said.

>I am sure that Bill is capable of coming
>up with the push_back_eof algorithm all by his little old self -- if, after
>considering the design aspects of the situation, he decides that is the
>behavior he wants.

You already stated the behavior that Bill wanted:  he wanted to make the
behavior of fread match the description in the manual page.  He did not
want to change the behavior of any other functions.

Of course Bill is capable of coming up with the push_back_eof algorithm
himself, but as it happens he did't.  He asked in his posting how fread
could be made to correspond to the manual page description of it without
changing getc, and I answered him.  None of this is intended as an attack
on Bill--any programmer is entitled to an occasional slip--but I wonder why
it wasn't caught before the release of 4.2.

>If you intend to write portable software, don't assume you can continue
>reading from a terminal after EOF.

And if I don't want to write software that is portable to anything other
than another UNIX system?  And anyway, I have never heard of a system that
couldn't support reading on a terminal after EOF.  Such a system would be
a bit awkward to use since every time you typed an EOF at your terminal
all programs, including the command processor, would presumably encounter
and EOF indication and you would be logged out.

>For my money, I would much rather pay
>a small backwards-compatibility price to achieve a stdio implementation that
>was truly portable.

Currently, stdio is not truly portable.  Try to implement fseek on a
non-UNIX system some time.  Stdio does hide differences between various
versions of UNIX and I am not suggesting that that should change.

>In any case, most programs that expect to get more than one EOF from a
>terminal are broken, because you will get different results if you redirect
>from a file.

Horrors, EMACS won't work if you redirect it's input to a file--I guess
we had better throw it out.  Seriously, differences between UNIX variants
create problems for people.  The idea that "they won't break very many
programs" is not a justification.  Obviously nobody would have raised the
issue if no programs were affected.

I can appreciate Bill Shannon's postion on fread, but changing the
functioning of getc is a different issue.
				Kenneth Almquist