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

[Carlos O'Donell <carlos at redhat dot com>]

On 09/17/2018 10:58 AM, Florian Weimer wrote:
> Andreas Schwab <schwab@suse.de> writes:
> 
>> On Sep 17 2018, Florian Weimer <fweimer@redhat.com> wrote:
>>
>>> 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.
>>
>> Is there any indication that there are more packages that depend on this
>> extension?
> 
> Not yet, no.

However, as Florian notes, when we see one failure like this in the corpus
of packages we ship it has historically been an indicator that there exists
code which also depends on it. This is just correlation, not causation though,
it might be that cups-filter is the only thing broken by this fix.

I'm inclined to side with Rich that "All bugs are extensions."

Is cups-filter fixed by inserting a clearerr(f)?

Or does glibc's current implementation disallow concat via dup2?

-- 
Cheers,
Carlos.