Re: gnulib portability issues

[Rich Felker]

On Sun, Jun 10, 2012 at 07:02:32PM -0700, Paul Eggert wrote:
> On 06/10/2012 06:10 AM, Rich Felker wrote:
> > As such, the first fix I would recommend is simply removing the check
> > for freadahead(stdin)>0 from closein.c
> 
> But that will hurt performance on GNU/Linux and most other
> POSIXish hosts, as it will cause them to issue lseek
> system calls and whatnot that they don't need.

If you think it matters, __freading could be used instead. I was
wrongly thinking fseek would be a no-op (and not call lseek) if
there's nothing buffered, but then of course it couldn't report the
file as non-seekable.

By the way, to answer your other email, musl's __freading returns 0/1,
not a count. This matters from a standpoint of implementing
freadahead, but closein.c only needs the boolean result, so it would
make the most sense to change closein.c to just use __freading (or the
gnulib freading function which can be implemented in terms of
__freading; it could in turn use the ugly dup/dup2 hackery we
discussed as a fallback implementation if the system does not have
stdio_ext functions).

> Instead, wouldn't it be better to change gnulib/lib/stdio-impl.h
> so that it groks the musl FILE object?  Naturally, this would
> inspect musl's "internals", but that'd be no different from
> all those other libraries that stdio-impl.h supports.

No, because I have no intention of keeping the internals fixed.
They're purposefully opaque so that they can be changed if an
alternate implementation proves better. Poking at the internals will
make binaries that could horribly break when upgrading libc, which is
not a good thing.

Rich