This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

On 20/09/2018 05:28, Florian Weimer wrote:
> * Florian Weimer:
>> 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
> The upstream bug: <>
>> 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.
> Folks,
> do I read the emerging consensus correctly as the following?
> glibc should not change (e.g., revert the fix for bug 1190) to paper
> over application bugs such as the bug in cups-filters.  Applications
> need to be fixed instead.  End users whose applications cannot be fixed
> should keep with previous glibc versions.

I agree with you on this specific issue, even more after the FreeBSD
ports required path indicated it is indeed an application problem.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]