[Toybox] freadahead()

[enh]

On Mon, Apr 11, 2022 at 11:25 PM Rob Landley <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>> 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?


> > 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.)
>
> There are a few exceptions.
>
> >     Honestly, I
> >     have no sympathy for the glibc guys who implemented everything EXCEPT
> >     __freadahead() because they want to force people to use
> >     gnugnugnustallmanftaghnlib:
> >
> >
> > citation needed :-)
>
> If you want a list of what they DID implement, the man page I linked to
> lists
> them. (It's one of them group man pages for a bunch of related features.)
>

i know what they did do, because bionic got its subset via man7.org :-) i
just didn't realize until now that musl's set != glibc's set.


> If you want examples of gnu pressuring people to use their libraries to
> spread
> their license... they've been pretty open about it? Their darling used to
> be
> libreadline before that got cloned...
>
> https://www.gnu.org/licenses/why-not-lgpl.en.html
> https://news.ycombinator.com/item?id=20772053#:~:text=embraced
>
> There are more explicit on-topic references, but... sigh, stuff wanders by
> over
> the years that can be a bit hard to dig up again. They've been at this
> FOREVER...
>
> https://postgrespro.com/list/thread-id/1596439
>
> That whole
>
> https://www.computerworld.com/article/2732025/gpl-enforcement-sparks-community-flames.html
> thing was not my first licensing rodeo. I first encountered the GPL via
> the EMX
> project back in college like a decade before that:
>
>   https://en.wikipedia.org/wiki/EMX_(programming_environment)
>
> My first serious attempt to educate myself on IP law was over 20 years ago
> now,
> sometime before... Grrr, TMF keeps moving their archives around. Lemme
> splice
> together the week with my own archives...
>
> https://landley.net/writing/mirror/fool/rulemaker000501.htm
>
> https://www.fool.com/archive/portfolios/rulemaker/2000/05/02/get-your-copyrights-here.aspx
>
> https://www.fool.com/archive/portfolios/rulemaker/2000/05/03/you-gonna-patent-that.aspx
> http://landley.net/writing/mirror/fool/rulemaker000504.htm
> http://landley.net/writing/mirror/fool/rulemaker000505.htm
>
> I.E. sometime before that.
>
> I even drove to Boston to talk to Richard Stallman at his office in
> February
> 2001. (I'd already mailed him a VHS copy of the musical 1776, so I could
> explain
> he was John Adams and needed ESR's Franklin and Torvalds' Jefferson to get
> his
> agenda through. He didn't take that well, he thought he was Franklin.
> Sigh.)
>
> Anyway, I was very interested in the IP considerations and ramifications
> of all
> this stuff because licensing and development model were a big part what
> made
> Linux different, and I wanted to understand it. I think
> https://lkml.org/lkml/2002/6/3/199 is why I was cc'd on
>
> https://mail.gnome.org/archives/foundation-list/2004-September/msg00014.html
> but
> it's been a while?
>
> Oh, and at this LinuxWorld Expo in 2000:
>
>
> https://www.fool.com/archive/portfolios/rulemaker/2000/08/18/is-amds-chip-better-than-intels.aspx
>
> I attended a talk where Stallman was VERY UNHAPPY with the "application
> service
> provider" problem where people could run GPL code on a server and not share
> modifications because they weren't distributing the code! He already was
> trying
> to figure out how to change the license to stop this, but the problem is
> since
> they weren't distributing but merely using copyright didn't actually give
> him
> any leverage. (He later switched to "tivoization" where he was instead
> basically
> undermining first sale doctrine. That might also be where I learned that
> GPL
> can't rely on contract law for anything because there's no "privity of
> contract": you haven't got an agreement if you can't say who your
> agreement is
> WITH. Alas the law has shifted a bit since then in truly horrible ways and
> the
> FSF has been on the wrong side of that...)
>
> So when I launched the first GPL enforcement suits in 2006 it didn't come
> out of
> nowhere. Almost immediately after that the FSF broke the GPL into warring
> camps
> and doomed it to irrelevance, and it took me something like 5 years to work
> through the kubler-ross stages of grief. (Maintaining "last GPLv2"
> versions of
> things involved both denial and anger. I did not bargain with the FSF ever
> because Rudyard Kipling was right about Danegeld, but there was a lot of
> negotation to get SPDX and OSI and github to accept 0BSD...)
>
> > i'd be genuinely curious to know why glibc doesn't have this (and
> especially
> > "why musl does anyway").
>
> Because people were patching a #define __MUSL__ into their toolchains so
> gnulib
> could poke at musl's FILE internals.
>
> https://lists.gnu.org/archive/html/bug-gnulib/2012-06/msg00223.html
>
> 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? 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'll have to check what else is in musl's <stdio_ext.h>
> > that isn't in glibc's. looks like these:
> >
> > size_t __freadahead(FILE *);
> > const char *__freadptr(FILE *, size_t *);
> > void __freadptrinc(FILE *, size_t);
>
> So far I've just needed to answer the one question...
>

yeah, and __freadahead() does seem the least scary of the three.


> >       https://linux.die.net/man/3/__fpending
> >     <https://linux.die.net/man/3/__fpending>
> >
> >     They have _fbufsize() but not how much of the buffer is used. That's
> just sad.
> >
> > 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...)
>
> I need it because I CAN'T seek. If I could, I could just count the bytes
> returned by getline() and seek the fd to that position after calling
> fileno().
>
> 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.


> Rob
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20220412/2e06ac23/attachment-0001.htm>