On Mon, Apr 11, 2022 at 11:25 PM Rob Landley <[email protected]> wrote:
> On 4/11/22 19:03, enh wrote: > > On Mon, Apr 11, 2022 at 3:19 PM Rob Landley <[email protected] > > <mailto:[email protected]>> 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 >
_______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
