[Toybox] freadahead()

[Rob Landley]

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/austin-group-l@opengroup.org/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