This is the mail archive of the libc-alpha@sourceware.org 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]


Rich Felker <dalias@libc.org> writes:

>> 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.

True.

>> 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.

We already do an fstat, so we could capture the device/inode information
and capture that to be reused at a later EOF.

To version the fix, symbol versioning would have to be introduced for
all functions which create descriptors, and the fix would have to be
reverted in 2.28 because no new symbol versions can be added after a
release.

> 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?

The current dependencies of cups-filters look sufficiently heavy that
it's possible that only glibc targets were used with it.

Thanks,
Florian


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