This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |