Elliott: could you add __freadahead() to bionic the way musl and z/os and so on have?
I'm bothering the posix guys about this, thread starts here: https://www.mail-archive.com/[email protected]/msg09468.html The problem is calling getline() then calling fileno() and reading from that can miss data in the FILE * buffer, and that's why patch.c is still using get_line() to do byte at a time reads so it can hand off to sendfile() when it runs out of hunks. It's also what wget wants for zlib support, it's likely to come up in Moritz' implementation of git, and so on. Basically anything with an smtp/mbox ancestry that needs a filehandle to process the "body" after the keyword: value headers. Unfortunately the ANSI C guys pointed out they don't do anything with file descriptors (no open() no read() no nothing), which is why fdopen() and fileno() (and for that matter getline()) live in posix, not ANSI C. But the Posix guys are so far saying (in private email, not to the list, sigh) that mucking about with the internals of an ANSI struct is thing that ANSI should do, not them. Except fileno() already does that, and ANSI hasn't got getline(), so the use case for this does not exist over there. You can ONLY access files through FILE * in pure ANSI C, so there's no context switching that can miss data... Anyway, if musl and bionic have __freadahead(), I can either #ifdef the glibc hack for it in portability.h, or might just move xgetline() into portability.c and have it do get_line() on systems that don't have __freadahead(). Honestly, I have no sympathy for the glibc guys who implemented everything EXCEPT __freadahead() because they want to force people to use gnugnugnustallmanftaghnlib: https://linux.die.net/man/3/__fpending They have _fbufsize() but not how much of the buffer is used. That's just sad. You can ask this question for output, but not for input. (And given that you can't plug the output any data you wrote might already have been sent so being able to "unsend" it without seeking is never reliable... sigh.) Rob _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
