On Thu, Nov 29, 2018 at 5:27 PM Rob Landley <r...@landley.net> wrote: > > > > On 11/28/18 7:15 PM, enh wrote: > > On Wed, Nov 28, 2018 at 5:11 PM Rob Landley <r...@landley.net> wrote: > >> > >> On 11/28/18 2:30 PM, enh via Toybox wrote: > >>> bionic, glibc, macOS, and musl all have strcasestr > >>> (see http://man7.org/linux/man-pages/man3/strstr.3.html). > >> > >> Dear posix: catch up to reality. I'm sure there's a nice farm somewhere > >> willing > >> to take Jorg Schilling where he can tell everyone how much better Solaris > >> was > >> than Linux to his heart's content. > >> > >>> +#include <string.h> > >>> +char *strcasestr(const char *haystack, const char *needle); > >>> + > >> > >> Why are you including string.h here? That's 3 includes of it (it's in the > >> posix > >> headers in toys.h after all the portability stuff, and under __BIONIC__, > >> and now > >> here under __GLIBC__. The standard #includes are after the portability.h > >> stuff > >> so that can override them, but > > > > iirc i was just following the style. > > > > i did need a `#include <stdio.h>` elsewhere (i'll get round to that > > patch at some point), and may just have done this by analogy. > > The string.h before strcasestr() isn't needed, but the one before confstr is: > > ./lib/portability.h:257:52: note: include the header <string.h> or explicitly > provide a declaration foqr 'strcpy' > In file included from ./toys.h:9: > ./lib/portability.h:257:52: error: implicitly declaring library function > 'strcpy' with type 'char *(char *, const char *)' > > For strcpy(). Also, building with the NDK: > > .toys/lsb/mktemp.c:51:5: warning: 'mktemp' is deprecated: mktemp is unsafe, > use > mkstemp or tmpfile instead [-Wdeprecated-declarations] > mktemp(template); > ^ > /opt/android/x86_64/bin/../sysroot/usr/include/stdlib.h:68:47: note: 'mktemp' > has been explicitly marked deprecated here > char* mktemp(char* __template) __attribute__((deprecated("mktemp is unsa... > ^ > 1 warning generated. > > Why is it unsafe? (musl and glibc don't complain...)
dunno about musl, but glibc does (just at link time rather than compile time --- iirc we no longer have any link-time warnings in bionic, just compile time ones). these days it's just the TOCTOU race inherent in the function, but according to http://man7.org/linux/man-pages/man3/mktemp.3.html some historical implementations are exceptionally collision-prone. (this is one advantage of the compile-time warning: you can add the pragma to the source explaining why you're happy making the trade-off. whereas turning off all linker warnings, well, i wish i could claim i've never seen anyone do that, but that would be a lie.) > >> Sigh. I'm willing to take your word that this is the right thing to do, > >> but it > >> makes me nervous... > > > > i didn't really understand why you were so against _GNU_SOURCE. > > duplicating prototypes seems worse overall (as you mention in point 2 > > above). > > Because it isn't. It's Linux. aye, but neither is Android POSIX (in the sense that -- to my knowledge -- no-one's ever certified it). nor is it BSD (despite containing some BSD code). and yet folks say _POSIX_SOURCE and _BSD_SOURCE to use those APIs. it doesn't seem unreasonable to say _GNU_SOURCE for the GNU extensions. even if something like __USE_BSD_EXTENSIONS and __USE_GNU_EXTENSIONS might have been more intention-revealing. (who went first and started the _BLAH_SOURCE trend, i wonder?) > GNU was a failed 1980's Unix cloning effort (one > of several), Linux has nothing to do with it and never did (linux forked off > of > minix, an entirely separate unix cloning effort). Adding Linux system calls > like > unshare() not only isn't "gnu", it's something the glibc guys have been > editorializing about: > > https://lwn.net/Articles/771441/ for bionic, my rule of thumb is "three unrelated projects all need it". bonus points for being something that's a pain in the ass to use with syscall(3), such as the things that split 64-bit values in two. bonus points for being something that's already in at least one other libc. and, of course, having a bunch of functions that require a tid but not having a convenient gettid(2) wrapper --- only crazy people would have a libc like that :-) > One of my original motivations for this entire line of nonsense, as I noted in > http://landley.net/aboriginal/history.html , was: > > > (And then I'd ask Richard Stallman if a system without a line of gnu code > > anywhere in it was still Gnu/Linux/Dammit and mock him when he said yes.) > > It's not high on the list, but it's still in there. :) > > I may still have some residual guilt here from 1998: > > http://www.kerneltraffic.org/kernel-traffic/kt20020805_178.html#1 lol. i didn't realize that was your fault! > The _misconception_ that Linux has something to do with the GNU project is > because Richard Stallman took advantage of Java to lie about Linux's history. > > Java united the "anything but microsoft" crowd starting about 1995 (collecting > most of the old proprietary Unix, MacOS, OS/2, Amiga and DOS holdouts under a > single banner), and then in 1998 when it released its source code and cited > the > Cathedral and the Bazaar as the reason, it pointed them all at Linux, and the > Linux userbase famously grew 212% in one year (TRIPLED in size), and _none_ of > those new guys knew the history of the Linux project. > > The existing Linux devs were saturated trying to bring everybody up to speed > on > the technology so didn't have cycles to spare for enculturation, and Richard > Stallman saw his chance and lied to everybody. When they asked "where did all > this come from", he fed them the history of his GNU project instead, which was > NOT the history of Linux. This pissed Linus off big time. Linux started on > comp.os.minix after Linus had an OS design course using Tanenbaum's textbook, > its first filesystem was the minix filesystem... he never tried to hide its > real > ancestry. Heck: > > https://www.oreilly.com/openbook/opensources/book/appa.html > > It's really, really not a secret. But the one thing Stallman's ever really > been > outstanding at is self-promotion, and he is _relentless_ at it. He's convinced > multiple authors to write large chunks of books about him (Steven Levy's > "Hackers", "Free as in Freedom", etc). Show me equivalent books written about > _Ken_Thompson_... > > Sorry, you can't do much computer history research without starting to really > hate Stallman for persistently and intentionally distorting the historical > record to inflate his own self-importance. (Although in fairness I'm pretty > sure he lies to _himself_, believes his own press releases, and goes from > there.) > > Rob _______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net