What to do about gnulib libio dependencies?

[Eric Blake]

On 08/21/2018 12:54 PM, Paul Eggert wrote:
> Zack Weinberg wrote:
> 
>> I think it would clarify this discussion if you gave concrete examples
>> of existing programs that use these functions, and described what they
>> are doing with them that can't be accomplished using the standard
>> interfaces.
> 
> No GNU utility cares about wide streams that I know of. Wide streams 
> were a mistake as far as I can tell.

Agreed; and libunistring actively documents against using wide functions:
https://www.gnu.org/software/libunistring/manual/libunistring.html#The-wchar_005ft-mess

> 
> As I recall, the most important user of the gnulib libio dependencies is 
> GNU m4, which uses freadptr and freadseek for efficiency. GNU 'cut' is 
> in the same camp, though it's less important.
> 
> GNU coreutils uses freadahead when deciding whether to fflush stdin, 
> although I think this is a relatively minor optimization and wouldn't be 
> a major loss if it went away.
> 
> I'll CC: this to Bruno Haible, who has more experience in this area. 
> Bruno, the proposal on the table is for glibc to remove the undocumented 
> features that let Gnulib implement fbufmode, freadahead, freadptr, 
> freadseek, and fseterr; or instead, for glibc to export these features 
> somehow in a way that Gnulib can access in a documented way. Please see 
> the thread starting here:
> 
> https://sourceware.org/ml/libc-alpha/2018-08/msg00412.html

For historical comparison, DragonflyBSD exported __sreadahead as an 
interface precisely so that they could make FILE* become more opaque, 
while still providing the optimizations that gnulib relies on via these 
modules:

https://lists.gnu.org/archive/html/bug-gnulib/2008-04/msg00282.html

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org