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

[Rich Felker <dalias at libc dot org>]

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.

Rich