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: BZ #1190: stream behaviour on encountering an EOF


On Thu, Sep 13, 2012 at 11:28:24AM -0700, Paul Eggert wrote:
> Another possible way forward is to document glibc's departure from C99
> and from POSIX, and try to get the standards changed the next time
> around, as it's too late for C11 and for the next POSIX release.  The
> argument would be that this longstanding compatibility issue hasn't
> gone away simply because the standardizers said so.

Are you aware that the only applications that can see the difference
are applications reading input from a terminal where the interactive
user has pressed ^D (or whatever the stty-configured EOF key is) on a
blank line to feed the program an EOF, which attempt subsequent reads
without calling clearerr() on the FILE? Thus, it's not something that
affects major applications, and in fact it does not affect the
internal workings of ANY application (except those using pseudo-ttys
internally in very odd ways, which I could describe if anybody cares),
only particular patterns of user-interaction (using ^D).

I really don't see any way that fixing this bug in glibc could break
anything; the reluctance to fix it seems to be purely the conservative
maintainership philosophy lingering from the Drepper era, whereby
fixing bugs was not allowed on the theory that some application might
depend on the bug. In general there's at least some valid argument for
that philsophy, but in the case of this bug, I cannot see any
legitimate argument for how fixing it could break anything.

Rich


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