<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Apr 11, 2022 at 3:19 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">Elliott: could you add __freadahead() to bionic the way musl and z/os and so on<br>
have?<br>
<br>
I'm bothering the posix guys about this, thread starts here:<br>
<br>
  <a href="https://www.mail-archive.com/austin-group-l@opengroup.org/msg09468.html" rel="noreferrer" target="_blank">https://www.mail-archive.com/austin-group-l@opengroup.org/msg09468.html</a><br>
<br>
The problem is calling getline() then calling fileno() and reading from that can<br>
miss data in the FILE * buffer, and that's why patch.c is still using get_line()<br>
to do byte at a time reads so it can hand off to sendfile() when it runs out of<br>
hunks. It's also what wget wants for zlib support, it's likely to come up in<br>
Moritz' implementation of git, and so on. Basically anything with an smtp/mbox<br>
ancestry that needs a filehandle to process the "body" after the keyword: value<br>
headers.<br>
<br>
Unfortunately the ANSI C guys pointed out they don't do anything with file<br>
descriptors (no open() no read() no nothing), which is why fdopen() and fileno()<br>
(and for that matter getline()) live in posix, not ANSI C.<br>
<br>
But the Posix guys are so far saying (in private email, not to the list, sigh)<br>
that mucking about with the internals of an ANSI struct is thing that ANSI<br>
should do, not them. Except fileno() already does that, and ANSI hasn't got<br>
getline(), so the use case for this does not exist over there. You can ONLY<br>
access files through FILE * in pure ANSI C, so there's no context switching that<br>
can miss data...<br>
<br>
Anyway, if musl and bionic have __freadahead(), I can either #ifdef the glibc<br>
hack for it in portability.h, or might just move xgetline() into portability.c<br>
and have it do get_line() on systems that don't have __freadahead(). </blockquote><div><br></div><div>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.)</div><div><br></div><div>yeah, iirc i added everything that glibc had but didn't even look at musl. (if you'd asked me even this morning, i'd have told you musl was a strict subset of glibc. TIL.)</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">Honestly, I<br>
have no sympathy for the glibc guys who implemented everything EXCEPT<br>
__freadahead() because they want to force people to use gnugnugnustallmanftaghnlib:<br></blockquote><div><br></div><div><div>citation needed :-)</div></div><div><br></div><div>i'd be genuinely curious to know why glibc doesn't have this (and especially "why musl does anyway"). i'll have to check what else is in musl's <stdio_ext.h> that isn't in glibc's. looks like these:</div><div><br></div><div>size_t __freadahead(FILE *);<br>const char *__freadptr(FILE *, size_t *);<br>void __freadptrinc(FILE *, size_t);<br></div><div><br></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">
  <a href="https://linux.die.net/man/3/__fpending" rel="noreferrer" target="_blank">https://linux.die.net/man/3/__fpending</a><br>
<br>
They have _fbufsize() but not how much of the buffer is used. That's just sad.<br></blockquote><div><br></div><div>that does seem of questionable utility now you bring it up. (though as you pointed out on the posix list, unless you _know_ you can seek on a stream, all of this is pretty dodgy...)</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
You can ask this question for output, but not for input. (And given that you<br>
can't plug the output any data you wrote might already have been sent so being<br>
able to "unsend" it without seeking is never reliable... sigh.)<br>
<br>
Rob<br>
</blockquote></div></div>