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
