Re: What to do about gnulib libio dependencies?

[Florian Weimer <fweimer at redhat dot com>]

On 08/21/2018 03:18 PM, Zack Weinberg wrote:
> Well, the question in my mind is, how much harm will it be?  I don't
> see how we can assess the tradeoff between consequences for external
> applications and increased maintenance burden for us, without knowing
> how important these APIs are to external applications.  I would also
> want to dig into just how invasive of libio internals these APIs
> actually are.  If they're like the stuff in stdio_ext.h, that's not a
> big deal, but if they involve messing with vtables or forcing us to
> preserve the C++-stream distinction between put and get pointers or
> something on that level, that would be much more of a problem, IMO.

Going by the source files are included in the debuginfo data (that is, 
actually compiled and linked in), I see the following packages using 
fseterr:

bison
coreutils
dc3dd
gzip
lbzip2
libunistring
pspp
recutils

freadahead is used by:

coreutils
findutils
m4

coreutils also uses freadptr and freadseek.

I do not see any use of fbufmode.

fpurge is also used fairly widely (bash, lftp, libbsd, libexplain, 
libprelude, libvirt, oath-toolkit), but we already provide __fpurge, and 
the gnulib implementation of fpurge should simply wrap our __fpurge.

fseterr looks pretty harmless to support.  freadahead and freadptr are 
problematic for wide-oriented streams, but we have ABI exposure for the 
read pointers already for the inline copy of fputc_unlocked.  The only 
caveat is that for fputc_unlocked, we can provide compatibility by 
always having an empty read buffer (at a cost to performance).  With the 
other interfaces, this might not be a possibility.

Thanks,
Florian