[Toybox] freadahead()

[enh]

On Tue, Apr 12, 2022 at 9:02 PM Rob Landley <rob at landley.net> wrote:

> 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.
>

well, that took a while, but better late than never:
https://android-review.googlesource.com/c/platform/bionic/+/2227544


> Rob
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20220922/370a248b/attachment.htm>