[Toybox] freadahead()

[Rob Landley]

On 4/12/22 20:39, enh wrote:> On Mon, Apr 11, 2022 at 11:25 PM Rob Landley
<rob at landley.net
> <mailto:rob at landley.net>> wrote:
> 
>     On 4/11/22 19:03, enh wrote:
>     > On Mon, Apr 11, 2022 at 3:19 PM Rob Landley <rob at landley.net
>     <mailto:rob at landley.net>
>     > <mailto:rob at landley.net <mailto:rob at landley.net>>> wrote:
>     >     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().
>     >
>     > you're still screwed on macOS? (oh, except macOS seems to be just the regular
>     > BSD header, with everything public and "roughly what you'd expect", so that's
>     > easily done manually too.)
> 
>     There's a bunch of stuff in the m4 and glib #ifdefs that show how to do it for
>     other libraries, although I only really care about 3 and can fall back to
>     get_line() for the others in portability.c. :)
> 
>     But part of my thinking is it's easier to convince the posix guys to standardize
>     the wrapper if the wrapper is more widely implemented. It's already in musl,
>     Dragonfly BSD, Z/OS...
> 
> yeah, "standardize existing practice" is what they're supposed to do, but they
> can be pretty slow even then. you might also want to
> try https://www.openwall.com/lists/libc-coord/2020/01/30/1

I'll poke Rich, the musl list is already on openwall and I'm pretty sure he's on
there already. :)

>     Rich has always had a weird reluctance to have a #define admitting you're using
>     musl. (That's why my mcm-buildall.sh has to append it to features.h after each
>     toolchain build.) Instead he added __freadahead() so autoconf could probe for
>     that and use it, avoiding the staircase function entirely.
> 
> so no-one's even mentioned this to glibc?

Dunno. I approached busybox before coreutils for a reason. A lawyer I used to
know described her profession as "sticking my hands in other people's toilets",
which is pretty much how I feel about interacting directly with Gnu projects. I
_can_ do it, but it's not my first choice. (There's some emotional scar tissue
involved in this reluctance.) And when it does happen, I expect it drag on for a
while, ala:

https://lists.gnu.org/archive/html/coreutils/2022-04/msg00010.html

> or they have, and they were happy with
> people poking at their fields? (might be worth mentioning on libc-coord if
> no-one's ever even mentioned it to them.)

I was vaguely assuming one of the people who poked Rich to add the feature, or
one of the gnu m4 developers, or one of the gnulib developers, would have raised
this issue with the gnu libc developers at some point over the past 15 years,
but no I'm not personally aware of the communication history.

I was sort of vaguely in touch with the eglibc developers for a bit, but when
glibc did the "gcc has recaptured egcs! The FSF is once again firmly in
control!" thing I backed away slowly maintaining eye contact until it was safe
to run.

>     The number I'm looking for is "how many bytes can I read from the FILE pointer
>     without triggering another underlying read from the fd" because I can't re-read
>     that data from the fd. So I need to fetch the data out of the buffer and handle
>     it before calling the "takes the rest as a filehandle" function. In the case of
>     patch.c, something like reading the remaining FILE * data into toybuf() and
>     doing a write() to the output fd before calling sendfile().
> 
> ah, right. that makes more sense. yeah, i'll add this.

Yay! Thank you.

Rob