no need to pass unnecessary extra arguments on to the core code in
pthread_create.c. this just wastes cycles and code bloat.

i originally made it the same size as the bloated GNU version, which
contains space for saved signal mask, but this makes some structures
containing jmp_buf become much larger for no benefit. we will never
use the signal mask field with plain setjmp; sigsetjmp serves that
purpose.

i made a best attempt, but the intended semantics of this function are
fundamentally contradictory. there is no consistent way to handle
ownership of locks when forking a multi-threaded process. the code
could have worked by accident for programs that only used normal
mutexes and nothing else (since they don't actually store or care
about their owner), but that's about it. broken-by-design interfaces
that aren't even in glibc (only solaris) don't belong in musl.

this is actually rather ugly, and would get even uglier if we ever
want to support further feature test macros. at some point i may
factor the bits headers into separate files for C base, POSIX base,
and nonstandard extensions (the only distinctions that seem to matter
now) and then the logic for which to include can go in the main header
rather than being duplicated for each arch. the downside of this is
that it would result in more files having to be opened during
compilation, so as long as the ugliness does not grow, i'm inclined to
leave it alone for now.

there is no reason to avoid multiple identical macro definitions; this
is perfectly legal C, and even with the maximal warning options
enabled, gcc does not issue any warning for it.

its only purpose was for use on non-BSD systems that implement sysv
semantics for signal() by default.

patch by Isaac Dunham. matched closely (maybe not exact) to glibc's
idea of what _BSD_SOURCE should make visible.

it's ok to overlap with integer slot 3 on 32-bit because only slots
0-2 are used on process-local barriers.

these are cruft from the original code which used an explicit string
length rather than null termination. i blindly converted all the
checks to null terminator checks, without noticing that in several
cases, the subsequent switch statement would automatically handle the
null byte correctly.

i don't understand why this has to be conditional on being in BRE
mode, but enabling this code unconditionally breaks a huge number of
ERE test cases.

i've been trying out openmp and it seems like it won't be much use
without this...

we do not bother making h_errno thread-local since the only interfaces
that use it are inherently non-thread-safe. but still use the
potentially-thread-local ABI to access it just to avoid lock-in.

written to avoid multiple conditional jumps and avoid ugly repetitive
lines in the header file.

this one is for program(s|ers) who haven't heard of uint16_t and
uint32_t (which are obviously the correct types for use in such
situations, as they're the argument/return types for ntohs/htons and
ntohl/htonl).

there's no sense in using a powerful lock in exit, because it will
never be unlocked. a thread that arrives at exit while exit is already
in progress just needs to hang forever. use the pause syscall for this
because it's cheap and easy and universally available.

this is all junk, but some programs use it.

the non-prototype declaration of basename in string.h is an ugly
compromise to avoid breaking 2 types of broken software:

1. programs which assume basename is declared in string.h and thus
would suffer from dangerous pointer-truncation if an implicit
declaration were used.

2. programs which include string.h with _GNU_SOURCE defined but then
declare their own prototype for basename using the incorrect GNU
signature for the function (which would clash with a correct
prototype).

however, since C++ does not have non-prototype declarations and
interprets them as prototypes for a function with no arguments, we
must omit it when compiling C++ code. thankfully, all known broken
apps that suffer from the above issues are written in C, not C++.

backported fix from freebsd:
http://svnweb.FreeBSD.org/base?view=revision&revision=233973