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
