Re: Sticky EOF breaks stream concatenation via dup2 [BZ #23636]

[Rich Felker <dalias at libc dot org>]

On Mon, Sep 17, 2018 at 04:37:55PM +0200, Florian Weimer wrote:
> Rich Felker <dalias@libc.org> writes:
> 
> > On Mon, Sep 17, 2018 at 03:37:03PM +0200, Florian Weimer wrote:
> >> Do we have to revert the fix fpr bug 1190 (which introduces sticky
> >> EOF for stdio streams)?
> >> 
> >> We received a bug report that cups-filters is quite broken due to
> >> this change, and while reviewing the libio sources, I found evidence
> >> that what cups-filters does (dup2-ing another descriptor after EOF)
> >> was once considered supported (in _IO_new_file_underflow):
> >> 
> >>   fp->_IO_read_end += count;
> >>   if (count == 0)
> >>     {
> >>       /* If a stream is read to EOF, the calling application may
> >> switch active
> >> 	 handles.  As a result, our offset cache would no longer be valid, so
> >> 	 unset it.  */
> >>       fp->_offset = _IO_pos_BAD;
> >>       return EOF;
> >>     }
> >> 
> >> Usually, when our own testing finds bugs, that's that's just a small
> >> subset of what the larger user community (many of whom cannot
> >> recompile their applications) will experience once they upgrade, so
> >> I'm quite worried about the implications of the fix for bug 1190.
> >
> > I've always considered dup2'ing to temporarily or permanently switch
> > the fd underlying a FILE to be reasonable usage, since it's something
> > that needs to be doable (especially for the standard streams, which
> > can't be replaced) and freopen has multiple fatal flaws that make it
> > unsuitable to the task. However this does not absolve the appliction
> > of a requirement to clear the EOF status if the stream might be at EOF
> > when switching. Failure to do so is an application bug that was masked
> > by the glibc bug.
> 
> What worries me that we have had code for a long time, explicitly
> enabling applications which do *not* seek, beyond the fact that we
> simply did not implement sticky EOF.

You don't need to seek to clear it; clearerr(f) is the easiest way.

> This could perhaps be considered a glibc extension.

All bugs are extensions. :-)

If it's really a problem maybe there's some mechanism for versioning
the fix or otherwise maintaining compatibility with existing
applications (e.g. when hitting sticky EOF, probing whether the
underlying open file is still the same), but I really hope this
doesn't derail the fix.

Getting back to the particular software broken, cups-filter, how did
it work on non-glibc systems without this bug? Was the code being used
glibc-specific? Or was it just untested elsewhere?

Rich