<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Apr 12, 2022 at 9:02 PM Rob Landley <<a href="mailto:rob@landley.net">rob@landley.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 4/12/22 20:39, enh wrote:> On Mon, Apr 11, 2022 at 11:25 PM Rob Landley<br>
<<a href="mailto:rob@landley.net" target="_blank">rob@landley.net</a><br>
> <mailto:<a href="mailto:rob@landley.net" target="_blank">rob@landley.net</a>>> wrote:<br>
> <br>
> On 4/11/22 19:03, enh wrote:<br>
> > On Mon, Apr 11, 2022 at 3:19 PM Rob Landley <<a href="mailto:rob@landley.net" target="_blank">rob@landley.net</a><br>
> <mailto:<a href="mailto:rob@landley.net" target="_blank">rob@landley.net</a>><br>
> > <mailto:<a href="mailto:rob@landley.net" target="_blank">rob@landley.net</a> <mailto:<a href="mailto:rob@landley.net" target="_blank">rob@landley.net</a>>>> wrote:<br>
> > Anyway, if musl and bionic have __freadahead(), I can either #ifdef<br>
> the glibc<br>
> > hack for it in portability.h, or might just move xgetline() into<br>
> portability.c<br>
> > and have it do get_line() on systems that don't have __freadahead().<br>
> ><br>
> > you're still screwed on macOS? (oh, except macOS seems to be just the regular<br>
> > BSD header, with everything public and "roughly what you'd expect", so that's<br>
> > easily done manually too.)<br>
> <br>
> There's a bunch of stuff in the m4 and glib #ifdefs that show how to do it for<br>
> other libraries, although I only really care about 3 and can fall back to<br>
> get_line() for the others in portability.c. :)<br>
> <br>
> But part of my thinking is it's easier to convince the posix guys to standardize<br>
> the wrapper if the wrapper is more widely implemented. It's already in musl,<br>
> Dragonfly BSD, Z/OS...<br>
> <br>
> yeah, "standardize existing practice" is what they're supposed to do, but they<br>
> can be pretty slow even then. you might also want to<br>
> try <a href="https://www.openwall.com/lists/libc-coord/2020/01/30/1" rel="noreferrer" target="_blank">https://www.openwall.com/lists/libc-coord/2020/01/30/1</a><br>
<br>
I'll poke Rich, the musl list is already on openwall and I'm pretty sure he's on<br>
there already. :)<br>
<br>
> Rich has always had a weird reluctance to have a #define admitting you're using<br>
> musl. (That's why my mcm-buildall.sh has to append it to features.h after each<br>
> toolchain build.) Instead he added __freadahead() so autoconf could probe for<br>
> that and use it, avoiding the staircase function entirely.<br>
> <br>
> so no-one's even mentioned this to glibc?<br>
<br>
Dunno. I approached busybox before coreutils for a reason. A lawyer I used to<br>
know described her profession as "sticking my hands in other people's toilets",<br>
which is pretty much how I feel about interacting directly with Gnu projects. I<br>
_can_ do it, but it's not my first choice. (There's some emotional scar tissue<br>
involved in this reluctance.) And when it does happen, I expect it drag on for a<br>
while, ala:<br>
<br>
<a href="https://lists.gnu.org/archive/html/coreutils/2022-04/msg00010.html" rel="noreferrer" target="_blank">https://lists.gnu.org/archive/html/coreutils/2022-04/msg00010.html</a><br>
<br>
> or they have, and they were happy with<br>
> people poking at their fields? (might be worth mentioning on libc-coord if<br>
> no-one's ever even mentioned it to them.)<br>
<br>
I was vaguely assuming one of the people who poked Rich to add the feature, or<br>
one of the gnu m4 developers, or one of the gnulib developers, would have raised<br>
this issue with the gnu libc developers at some point over the past 15 years,<br>
but no I'm not personally aware of the communication history.<br>
<br>
I was sort of vaguely in touch with the eglibc developers for a bit, but when<br>
glibc did the "gcc has recaptured egcs! The FSF is once again firmly in<br>
control!" thing I backed away slowly maintaining eye contact until it was safe<br>
to run.<br>
<br>
> The number I'm looking for is "how many bytes can I read from the FILE pointer<br>
> without triggering another underlying read from the fd" because I can't re-read<br>
> that data from the fd. So I need to fetch the data out of the buffer and handle<br>
> it before calling the "takes the rest as a filehandle" function. In the case of<br>
> patch.c, something like reading the remaining FILE * data into toybuf() and<br>
> doing a write() to the output fd before calling sendfile().<br>
> <br>
> ah, right. that makes more sense. yeah, i'll add this.<br>
<br>
Yay! Thank you.<br></blockquote><div><br></div><div>well, that took a while, but better late than never: <a href="https://android-review.googlesource.com/c/platform/bionic/+/2227544">https://android-review.googlesource.com/c/platform/bionic/+/2227544</a></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Rob<br>
</blockquote></div></div>