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

[enh]

On Mon, Dec 3, 2018 at 12:09 PM enh <enh at google.com> wrote:
>
> On Mon, Dec 3, 2018 at 11:33 AM Rob Landley <rob at landley.net> wrote:
> >
> > On 12/3/18 12:00 PM, enh wrote:
> > > amusingly, the same line causes a (different) compile-time warning
> > > with old versions of glibc. glibc 2.15 at least has mktemp marked as
> > > warn_unused_result, and AOSP currently uses glibc 2.15 for host
> > > builds. i've sent a patch to fix that (and attached the same patch
> > > here too, in case the spam filter is still messing with you :-) ).
> >
> > I enabled the header rewrite whatsis in the list plumbing and that seems to have
> > fixed the worst of it.
> >
> > I was looking at doing my own mktemp with xgetrandom() but the x part says
> > "denial of service attack/exploit waiting to happen" when a script calls
> > NAME=$(mktemp) and gets an empty string with some discarded stderr output...
> >
> > If bionic and musl _both_ don't warn about it, it's a glibc bug. Still annoying,
> > but I'll leave it for now and check if I still feel like trying to do something
> > about it during pre-release cleanup...
>
> well:
>
> * POSIX 1003.1-2008 removed mktemp(3).
>
> * musl has no compile-time deprecation/warn_unused_result warnings for anything.
>
> * bionic _does_ have a compile-time deprecation warning for mktemp
> because _most_ callers shouldn't use it (and POSIX did remove it, even
> if it seems unlikely that any libc will remove it any time soon).
> mktemp(1) -u/--dry-run just happens to be a weird exception where two
> wrongs make a right.
>
> * glibc doesn't have a compile-time deprecation warning because it's
> guarded behind "are we pre-2008 POSIX?".
>
> * glibc does have a link-time deprecation warning.
>
> * old glibc did have a compile-time warn_unused_result warning, but
> apparently they've thought better of that since and removed the
> attribute.
>
> so it's all just a big mess, really :-)
>
> (and, yes, i have seen uses that can't actually write to the directory
> --- the basic [anti-]pattern seems to be "there's something exposed
> via something like /proc, i want a unique name in that namespace, but
> there's some other mechanism for creating the thing than mkdir(2)". as
> far as i can tell, these are tests rather than production code.)

this made me realize i should have a test for this, and writing the
test uncovered cases where the mktemp logic still wasn't right. i've
sent a new patch with the missing tests and a rewrite of the logic
that chooses between DIR, $TMPDIR, and /tmp.

> > > someone's looking at upgrading the host glibc, but 2.15 is just inside
> > > the 7-year rule. plus i assume you'll be happy to save a line anyway.
> > > i'm not sure why i didn't write it as one line in the first place...
> > > even i don't find it obfuscatory in this case.
> >
> > Applied.
>
> thanks.
>
> > Rob