Re: gnulib portability issues

[Rich Felker]

On Tue, Jun 12, 2012 at 06:12:39AM -0600, Eric Blake wrote:
> And this simple program proves that most libc know how to push back more
> than one byte, whether or not they differ from the original contents,
> and especially in the common case where the byte still fits in the
> buffer.  It's the corner case where the bytes being pushed back differ
> from the backing store, and where they don't fit in the normal buffer
> (perhaps because you have used setvbuf or friends), and therefore libc
> has to malloc() some pushback storage, and if the malloc fails then so
> does the ungetc().

This is where we (musl vs glibc and perhaps you) have very different
design philosophies. Using a single non-switchable buffer simplifies
all the stdio code paths a lot, and reduces the cost of unget/get
cycles. I wouldn't look fondly on changing this for the sake of
supporting something that the standard says applications can't rely
upon. Moreover, our stdio, aside from functions like fopen/fclose that
affect the open file list, are intentionally async-signal-safe
provided that the same FILE is not used in the signal handler and the
interrupted code. Of course the standard doesn't require this, but I
think this non-mandated behavior is a lot more useful certain
developers (possibly embedded/realtime folks targetting exactly one
OS/libc/piece of hardware) than arbitrary-length ungetc.

The reason I mention all this is to point out that "implementations
could just all do X and conform to our expectations" is often not as
simple as it sounds. Some implementations are just bad, but others
have very conscious decisions to do things differently, some of which
may be incompatible with the changes you would expect to be easy.

Rich