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

[Florian Weimer <fweimer at redhat dot com>]

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.  This could perhaps be considered a
glibc extension.

Thanks,
Florian