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

[Rich Felker <dalias at aerifal dot cx>]

On Thu, Sep 13, 2012 at 12:55:21PM -0700, Paul Eggert wrote:
> > I'm not sure if there are device-related cases,
> 
> There are.  Tape devices work that way.  I don't suggest using stdio
> on tape devices, but not everyone follows my suggestions....

I'm vaguely aware that tape devices have really weird behavior, but
I'm having a hard time seeing how a tape at EOF could come to have
more data available. Such usage seems really fragile anyway.

> > You identified one technical reason (growing regular files)
> 
> Terminals count too, surely.  They're probably more important than
> growing regular files.

But as I said, it only affects a particular user interaction behavior
unless you go out of your way to make a pseudo-tty setup to emulate
said user behavior. This is why I think it's unlikely to matter.

> And the issue can come up regardless of file type.  If the underlying
> file descriptor is closed and reopened, for example, a sticky-EOF
> fgetc will still report EOF; a nonsticky one won't.  It's true that
> applications aren't supposed to do that sort of thing, but some do
> anyway -- I've done it myself.

I've done it too, for exactly one purpose: when I want to create a
sticky EOF/error flag on the FILE. See the horrible code in gnulib for
doing this credited to me...

> > the whole sentiment against fixing it seems to be
> > non-technical and borderline cargo-culting.
> 
> Again, injecting politics here is not likely to help, so let's try to
> keep the discussion technical.

I agree my previous statements about past maintainership were
political, but I don't see how the above quoted sentiment is. By the
phrase "cargo culting", I'm referring to the practice of mimicing
something you've seen done elsewhere without a theory or evidence for
how it's actually beneficial to achieving any goal. I said borderline
because there is some resemblance of a theory (applications could
theoretically depend on the current behavior), but a lack of evidence
that anything really does.

Rich