[Toybox] [PATCH] macOS: replace local strnstr with strcasestr.

[enh]

On Thu, Nov 29, 2018 at 5:27 PM Rob Landley <rob at landley.net> wrote:
>
>
>
> On 11/28/18 7:15 PM, enh wrote:
> > On Wed, Nov 28, 2018 at 5:11 PM Rob Landley <rob at 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