Re: BZ #1190: stream behaviour on encountering an EOF

[Rich Felker <dalias at aerifal dot cx>]

On Thu, Sep 13, 2012 at 12:19:51PM -0700, Paul Eggert wrote:
> On 09/13/2012 12:05 PM, Rich Felker wrote:
> > the only applications that can see the difference
> > are applications reading input from a terminal
> 
> No, it can affect applications reading from a socket,
> or from various special devices.  It can even affect
> an application reading from a regular file, if the file
> happens to be growing.

A socket does not return EOF except when the other end was closed or
shutdown. It blocks or gives EAGAIN in nonblocking mode if no data is
available.

You're right about growing regular files though; I missed that case.

I'm not sure if there are device-related cases, but (1) I doubt
anybody uses stdio to read from odd devices, and (2) I suspect they
behave like pipes and sockets, blocking or reporting EAGAIN rather
than EOF if no data is available. I think it would be helpful to the
discussion if somebody could confirm or disprove these two points.

> > it's not something that affects major applications
> 
> Most major applications work in both traditional and
> in C99ish environments, so they should work
> regardless of whether EOF is sticky.  So in that sense,
> yes, I expect this change should not break most major
> applications.  But I wouldn't be surprised if it did
> break "minor" (GNU-only) applications.  And anyway
> the argument "it won't break anything" cuts both ways --
> if applications really don't care whether EOF is sticky,
> why should C99 insist on sticky-EOF and why should glibc
> change?

So that we're not repeating this stupid issue 10 years from now.

> > the reluctance to fix it seems to be purely the conservative
> > maintainership philosophy lingering from the Drepper era
> 
> Surely it would be better to keep this discussion technical
> rather than have it jump into the political arena.  Don't
> we already have enough politics in our lives?

You identified one technical reason (growing regular files) that the
issue of fixing this bug should look into how it affects applications.
But otherwise, the whole sentiment against fixing it seems to be
non-technical and borderline cargo-culting. Perhaps it was bad of me
to mention he-who-shall-not-be-named again, but it's really my hope
that glibc can move past that kind of maintainership...

Rich