patch by Isaac Dunham.

this macro is 100 on all archs, at least in userspace, according
to kernel headers.

1. wrong return value and missing errno for negative suffix len
2. failure to catch suffix len > strlen
3. remove unwanted clearing of input string in invalid case

based on patch contributed by Anthony G. Basile (blueness)

some issues remain with the filename generation algorithm and other
small bugs, but this patch has been sitting around long enough that I
feel it's best to get it committed and then work out any remaining
issues.

patch by Jens Gustedt.
previously, the intended policy was to use __environ in code that must
conform to the ISO C namespace requirements, and environ elsewhere.
this policy was not followed in practice anyway, making things
confusing. on top of that, Jens reported that certain combinations of
link-time optimization options were breaking with the inconsistent
references; this seems to be a compiler or linker bug, but having it
go away is a nice side effect of the changes made here.

based on patch by Isaac Dunham, moved to its own file to avoid
increasing bss on static linked programs not using this nonstandard
function but using the standard getgrent function, and vice versa.

this definitely has the potential to be a bikeshed topic, so some
justification is in order. most of the changes made fit into one of
the following categories:
1. alignment with text in posix, xsh 2.3
2. eliminating overly-specific text for shared error codes
3. making the message match more closely with the macro name
4. removing extraneous words

in particular, the EAGAIN/EWOULDBLOCK text is updated to match the
description of EAGAIN (which covers both uses) rather than saying the
operation would block, and ENOTSUP/EOPNOTSUPP is updated not to
mention sockets.

the distinction between ENFILE/EMFILE has also been clarified; ENFILE
is aligned with the posix text, and EMFILE, which lacks concise posix
text matching any historic message, is updated to emphasize that the
exhausted resource is not open files/open file descriptions, but
rather the integer 'address space' of file descriptors.

some messages may be further tweaked based on feedback.

arm eabi requires this symbol for static C++ dtors.
usually it is provided by libstdc++, but when a C++ program
doesn't use the std lib (free-standing), the libc has to provide
it.
this was encountered while building transmission, which
depends on such a C++ library (libutp).

this function is nearly identical to __cxa_atexit, but it has the
order of argumens swapped for "performance reasons".
see page 25 of

 http://infocenter.arm.com/help/topic/com.arm.doc.ihi0043d/IHI0043D_rtabi.pdf

there are other aeabi specific C++ support functions missing, but
it is not clear yet that GCC makes use of them so we omit them for
the moment.

this avoids duplicating the fragile logic for executing an external
program without fork.

read should never return anything but 0 or sizeof ec here, but if it
does, we want to treat any other return as "success". then the caller
will get back the pid and is responsible for waiting on it when it
immediately exits.

the proposed change was described in detail in detail previously on
the mailing list. in short, vfork is unsafe because:

1. the compiler could make optimizations that cause the child to
clobber the parent's local vars.

2. strace is buggy and allows the vforking parent to run before the
child execs when run under strace.

the new design uses a close-on-exec pipe instead of vfork semantics to
synchronize the parent and child so that the parent does not return
before the child has finished using its arguments (and now, also its
stack). this also allows reporting exec failures to the caller instead
of giving the caller a child that mysteriously exits with status 127
on exec error.

basic testing has been performed on both the success and failure code
paths. further testing should be done.

also, don't waste code/time on F_GETFL since pipes always have blank
flags initially (at least on old kernels, which are all this fallback
code matters for).

this change shaves ~1k off libc.so bss size, and also avoids hard
errors in the case where the static buffer was not large enough to
hold the result.

this whole framework is really ugly and might should be replaced or at
least heavily overhauled when some changes/factorizations are made to
getaddrinfo internals in the future.

they're supposed to return an error code rather than using errno.

this bug seems to have been introduced when the map_library signatures
was changed to return the mapping in a temp dso structure instead of
into separate variables.

this bug seems to have been around a long time.

this bug was introduced when support for application-provided stacks
was originally added.

the main goal of these changes is to address the case where an
application provides a stack of size N, but TLS has size M that's a
significant portion of the size N (or even larger than N), thus giving
the application less stack space than it expected or no stack at all!

the new strategy pthread_create now uses is to only put TLS on the
application-provided stack if TLS is smaller than 1/8 of the stack
size or 2k, whichever is smaller. this ensures that the application
always has "close enough" to what it requested, and the threshold is
chosen heuristically to make sure "sane" amounts of TLS still end up
in the application-provided stack.

if TLS does not fit the above criteria, pthread_create uses mmap to
obtain space for TLS, but still uses the application-provided stack
for actual call frame stack. this is to avoid wasting memory, and for
the sake of supporting ugly hacks like garbage collection based on
assumptions that the implementation will use the provided stack range.

in order for the above heuristics to ever succeed, the amount of TLS
space wasted on POSIX TSD (pthread_key_create based) needed to be
reduced. otherwise, these changes would preclude any use of
pthread_create without mmap, which would have serious memory usage and
performance costs for applications trying to create huge numbers of
threads using pre-allocated stack space. the new value of
PTHREAD_KEYS_MAX is the minimum allowed by POSIX, 128. this should
still be plenty more than real-world applications need, especially now
that C11/gcc-style TLS is now supported in musl, and most apps and
libraries choose to use that instead of POSIX TSD when available.

at the same time, PTHREAD_STACK_MIN has been decreased. it was
originally set to PAGE_SIZE back when there was no support for TLS or
application-provided stacks, and requests smaller than a whole page
did not make sense. now, there are two good reasons to support
requests smaller than a page: (1) applications could provide
pre-allocated stacks smaller than a page, and (2) with smaller stack
sizes, stack+TLS+TSD can all fit in one page, making it possible for
applications which need huge numbers of threads with minimal stack
needs to allocate exactly one page per thread. the new value of
PTHREAD_STACK_MIN, 2k, is aligned with the minimum size for
sigaltstack.

this way they'll go into .rodata, decreasing memory pressure.

this should generate faster and smaller code, especially with inline
syscalls. the conditional with cnt is ugly, but thankfully cnt is
always a constant anyway so it gets evaluated at compile time. it may
be preferable to make separate __wake and __wakeall macros without a
count argument.

priv flag is not used yet; private futex support still needs to be
done at some point in the future.

it's not clear to me at the moment whether the code that was removed
(and which is now being re-added) is needed, but it's far from being a
no-op, and i don't want to risk breaking regex in this release.

alternatively, we could define it in sys/socket.h since SO* is
reserved there, and tcp.h includes sys/socket.h in extensions mode.

note that SOL_TCP is simply wrong and it's only here for compatibility
with broken applications. the correct argument to pass for setting TCP
socket options is IPPROTO_TCP, which of course has the same value as
SOL_TCP but works everywhere.

report/patch by Hiltjo Posthuma <hiltjo@codemadness.org>

this is a trivial no-op, because dlclose never deletes libraries. thus
we might as well have it in the header in case some application wants
it, since we're already providing it anyway.

based on patch by Pierre Carrier <pierre@gcarrier.fr> that just added
the flag constant, but with minimal additional code so that it
actually works as documented. this is a nonstandard option but some
major software (reportedly, Firefox) uses it and it was easy to add
anyway.