Discussion:
[PATCH] macOS: replace local strnstr with strcasestr.
Add Reply
Rob Landley
2018-11-29 01:11:51 UTC
Reply
Permalink
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

The reasons I hadn't done that were:

1) It's gnu extension and didn't know where else has it. (Sounds like everybody
though.)

2) prototypes grow "const" and "restrict" and __attribute__ and such
semi-randomly, and if you don't get it exactly right the build breaks on a
not-exactly-matching duplicate prototype. (You'd think "what you put on the
stack matches" would be good enough, but no...)

I've cut and pasted a couple out of the posix spec (where it's _specified_ what
the prototype has to be), but glibc has a nasty habit of "that linux kernel
system call was exported when you #included the header, but then they shipped a
new version where you have to #define _gnugnuallhailstallman to get the function
they used to freely export and I don't trust them not to break random stuff.

Sigh. I'm willing to take your word that this is the right thing to do, but it
makes me nervous...

Rob
Rob Landley
2018-11-30 01:27:21 UTC
Reply
Permalink
Post by Rob Landley
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...)
Post by Rob Landley
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. 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/

One of my original motivations for this entire line of nonsense, as I noted in
(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

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
Rob Landley
2018-12-02 22:57:47 UTC
Reply
Permalink
Post by Rob Landley
/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).
Um, _you_ added this warning in commit 40a09367f6f9.

- if (d_flag ? !mkdtemp(template) : mkstemp(template) == -1) {
+ if (toys.optflags & FLAG_u) {
+ mktemp(template);

Why did you do that? (What's the issue you were trying to solve, exactly?)

Rob
Rob Landley
2018-12-03 19:33:17 UTC
Reply
Permalink
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...
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.

Rob

Loading...