On Tue, Apr 12, 2022 at 9:02 PM Rob Landley <r...@landley.net> wrote:
> On 4/12/22 20:39, enh wrote:> On Mon, Apr 11, 2022 at 11:25 PM Rob Landley > <r...@landley.net > > <mailto:r...@landley.net>> wrote: > > > > On 4/11/22 19:03, enh wrote: > > > On Mon, Apr 11, 2022 at 3:19 PM Rob Landley <r...@landley.net > > <mailto:r...@landley.net> > > > <mailto:r...@landley.net <mailto:r...@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 >
_______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
