fix length computation in dn_expand

there are two possible points where the length is evaluated: either
the first 'compression' jump, or the null terminator if no jumps have
taken place yet. the previous code only measured the length of the
first component.

de-duplicate dn_expand, fix return value and signature, clean up

the duplicate code in dn_expand and its incorrect return values are
both results of the history of the code: the version in __dns.c was
originally written with no awareness of the legacy resolver API, and
was later copy-and-paste duplicated to provide the legacy API.

this commit is the first of a series that will restructure the
internal dns code to share as much code as possible with the legacy
resolver API functions.

I have also removed the loop detection logic, since the output buffer
length limit naturally prevents loops. in order to avoid long runtime
when encountering a loop if the caller provided a ridiculously long
buffer, the caller-provided length is clamped at the maximum dns name
length.

add arm-optimized memcpy implementation from bionic libc

the approach of this implementation was heavily investigated prior to
adopting it. attempts to obtain similar performance with pure C code
were capping out at about 75% of the performance of the asm, with
considerably larger code size, and were fragile in that the compiler
would sometimes compile part of memcpy into a call to itself.
therefore, just using the asm seems to be the best option.

this commit is the first to make use of the new subarch-specific asm
framework. the new armel directory is the location for arm asm that
should not be used for all arm subarchs, only the default one. armhf
is the name of the little-endian hardfloat-ABI subarch, which can use
the exact same asm. in both cases, the build system finds the asm by
following a memcpy.sub file.

the other two subarchs, armeb and armebhf, would need a big-endian
variant of this code. it would not be hard to adapt the code to big
endian, but I will hold off on doing so until there is demand for it.

rework makefile subarch logic to allow shared files

instead of subarchs getting their own .s files which are used directly
by the makefile to replace the .c file, they now must provide a .sub
file whose contents are a pathname, relative to the location of the
.sub file, which will substitute for the .c file. essentially these
files are acting as symbolic links, but implemented as text files.

add missing MSG_EXCEPT in sys/msg.h

provide declarations for strtod_l and family

these aliases were originally intended to be for ABI compatibility
only, but their presence caused regressions in broken gnulib-based
software whose configure scripts detect the existing of these
functions then use them without declarations, resulting in bogus
return values.

add subarch asm support for PIC objects/shared libc

this rule was omitted in previous subarch asm commit

add missing a_or_l to atomic.h for non-x86 archs

this is needed for recently committed sigaction code

allow subarch-specific asm, including asm specific to the default

the default subarch is the one whose full name is just the base arch
name, with no suffixes. normally, either the asm in the default
subarch is suitable for all subarch variants, or separate asm is
mandatory for each variant. however, in the case of asm which is
purely for optimization purposes, it's possible to have asm that only
works (or only performs well) on the default subarch, and not any othe
the other variants. thus, I have added a mechanism to give a name to
the default variant, for example "armel" for the default,
little-endian arm. further such default-subarch names can be added in
the future as needed.

fix _NSIG and SIGRTMAX on mips

a mips signal mask contains 128 bits, enough for signals 1 through
128. however, the exit status obtained from the wait-family functions
only has room for values up to 127. reportedly signal 128 was causing
kernelspace bugs, so it was removed from the kernel recently; even
without that issue, however, it was impossible to support it correctly
in userspace.

at the same time, the bug was masked on musl by SIGRTMAX incorrectly
yielding 64 on mips, rather than the "correct" value of 128. now that
the _NSIG issue is fixed, SIGRTMAX can be fixed at the same time,
exposing the full range of signals for application use.

note that the (nonstandardized) libc _NSIG value is actually one
greater than the max signal number, and also one greater than the
kernel headers' idea of _NSIG. this is the reason for the discrepency
with the recent kernel changes. since reducing _NSIG by one brought it
down from 129 to 128, rather than from 128 to 127, _NSIG/8, used
widely in the musl sources, is unchanged.

fix definitions of WIFSTOPPED and WIFSIGNALED to support up to signal 127

mips has signal numbers up to 127 (formerly, up to 128, but the last
one never worked right and caused kernel panic when used), so 127 in
the "signal number" field of the wait status is insufficient for
determining that the process was stopped. in addition, a nonzero value
in the upper bits must be present, indicating the signal number which
caused the process to be stopped.

details on this issue can be seen in the email with message id
CAAG0J9-d4BfEhbQovFqUAJ3QoOuXScrpsY1y95PrEPxA5DWedQ@mail.gmail.com on
the linux-mips mailing list, archived at:
http://www.linux-mips.org/archives/linux-mips/2013-06/msg00552.html
and in the associated thread about fixing the mips kernel bug.

commit 4a96b948687166da26a6c327e6c6733ad2336c5c fixed the
corresponding issue in uClibc, but introduced a multiple-evaluation
issue for the WIFSTOPPED macro.

for the most part, none of these issues affected pure musl systems,
since musl has up until now (incorrectly) defined SIGRTMAX as 64 on
all archs, even mips. however, interpreting status of non-musl
programs on mips may have caused problems. with this change, the full
range of signal numbers can be made available on mips.

add pthread_setaffinity_np and pthread_getaffinity_np functions

add cpu affinity interfaces

this first commit just includes the CPU_* and sched_* interfaces, not
the pthread_* interfaces, which may be added later. simple
sanity-check testing has been done for the basic interfaces, but most
of the macros have not yet been tested.

change sigset_t functions to restrict to _NSIG

the idea here is to avoid advertising signals that don't exist and to
make these functions safe to call (e.g. from within other parts of the
implementation) on fake sigset_t objects which do not have the HURD
padding.

optimize posix_spawn to avoid spurious sigaction syscalls

the trick here is that sigaction can track for us which signals have
ever had a signal handler set for them, and only those signals need to
be considered for reset. this tracking mask may have false positives,
since it is impossible to remove bits from it without race conditions.
false negatives are not possible since the mask is updated with atomic
operations prior to making the sigaction syscall.

implementation-internal signals are set to SIG_IGN rather than SIG_DFL
so that a signal raised in the parent (e.g. calling pthread_cancel on
the thread executing pthread_spawn) does not have any chance make it
to the child, where it would cause spurious termination by signal.

this change reduces the minimum/typical number of syscalls in the
child from around 70 to 4 (including execve). this should greatly
improve the performance of posix_spawn and other interfaces which use
it (popen and system).

to facilitate these changes, sigismember is also changed to return 0
rather than -1 for invalid signals, and to return the actual status of
implementation-internal signals. POSIX allows but does not require an
error on invalid signal numbers, and in fact returning an error tends
to confuse applications which wrongly assume the return value of
sigismember is boolean.

fix missing errno from exec failure in posix_spawn

failures prior to the exec attempt were reported correctly, but on
exec failure, the return value contained junk.

block all signals, even implementation-internal ones, in faccessat child

the child process's stack may be insufficient size to support a signal
frame, and there is no reason these signal handlers should run in the
child anyway.

block signals during fork

there are several reasons for this. some of them are related to race
conditions that arise since fork is required to be async-signal-safe:
if fork or pthread_create is called from a signal handler after the
fork syscall has returned but before the subsequent userspace code has
finished, inconsistent state could result. also, there seem to be
kernel and/or strace bugs related to arrival of signals during fork,
at least on some versions, and simply blocking signals eliminates the
possibility of such bugs.

work around libraries with versioned symbols in dynamic linker

this commit does not add versioning support; it merely fixes incorrect
lookups of symbols in libraries that contain versioned symbols.
previously, the version information was completely ignored, and
empirically this seems to have resulted in the oldest version being
chosen, but I am uncertain if that behavior was even reliable.

the new behavior being introduced is to completely ignore symbols
which are marked "hidden" (this seems to be the confusing nomenclature
for non-current-version) when versioning is present. this should solve
all problems related to libraries with symbol versioning as long as
all binaries involved are up-to-date (compatible with the
latest-version symbols), and it's the needed behavior for dlsym under
all circumstances.

sys/personality.h: add missing C++ compat

sys/personality.h: add missing macros

add Big5 charset support to iconv

at this point, it is just the common base charset equivalent to
Windows CP 950, with no further extensions. HKSCS and possibly other
supersets will be added later. other aliases may need to be added too.

make fcvt decimal point location for zero make more sense

the (obsolete) standard allows either 0 or 1 for the decimal point
location in this case, but since the number of zero digits returned in
the output string (in this implementation) is one more than the number
of digits the caller requested, it makes sense for the decimal point
to be logically "after" the first digit. in a sense, this change goes
with the previous commit which fixed the value of the decimal point
location for non-zero inputs.

fix ecvt/fcvt decimal point position output

these functions are obsolete and have no modern standard. the text in
SUSv2 is highly ambiguous, specifying that "negative means to the left
of the returned digits", which suggested to me that 0 would mean to
the right of the first digit. however, this does not agree with
historic practice, and the Linux man pages are more clear, specifying
that a negative value means "that the decimal point is to the left of
the start of the string" (in which case, 0 would mean the start of the
string, in accordance with historic practice).

iconv support for legacy Korean encodings

like for other character sets, stateful iso-2022 form is not supported
yet but everything else should work. all charset aliases are treated
the same, as Windows codepage 949, because reportedly the EUC-KR
charset name is in widespread (mis?)usage in email and on the web for
data which actually uses the extended characters outside the standard
93x94 grid. this could easily be changed if desired.

the principle of this converter for handling the giant bulk of rare
Hangul syllables outside of the standard KS X 1001 93x94 grid is the
same as the GB18030 converter's treatment of non-explicitly-coded
Unicode codepoints: sequences in the extension range are mapped to an
integer index N, and the converter explicitly computes the Nth Hangul
syllable not explicitly encoded in the character map. empirically,
this requires at most 7 passes over the grid. this approach reduces
the table size required for Korean legacy encodings from roughly 44k
to 17k and should have minimal performance impact on real-world text
conversions since the "slow" characters are rare. where it does have
impact, the cost is merely a large constant time factor.

have new timer threads unblock their own SIGTIMER

unblocking it in the pthread_once init function is not sufficient,
since multiple threads, some of them with the signal blocked, could
already exist before this is called; timers started from such threads
would be non-functional.

add system for resetting TLS to initial values

this is needed for reused threads in the SIGEV_THREAD timer
notification system, and could be reused elsewhere in the future if
needed, though it should be refactored for such use.

for static linking, __init_tls.c is simply modified to export the TLS
info in a structure with external linkage, rather than using statics.
this perhaps makes the code more clear, since the statics were poorly
named for statics. the new __reset_tls.c is only linked if it is used.

for dynamic linking, the code is in dynlink.c. sharing code with
__copy_tls is not practical since __reset_tls must also re-zero
thread-local bss.

fix multiple bugs in SIGEV_THREAD timers

1. the thread result field was reused for storing a kernel timer id,
but would be overwritten if the application code exited or cancelled
the thread.

2. low pointer values were used as the indicator that the timer id is
a kernel timer id rather than a thread id. this is not portable, as
mmap may return low pointers on some conditions. instead, use the fact
that pointers must be aligned and kernel timer ids must be
non-negative to map pointers into the negative integer space.

3. signals were not blocked until after the timer thread started, so a
race condition could allow a signal handler to run in the timer thread
when it's not supposed to exist. this is mainly problematic if the
calling thread was the only thread where the signal was unblocked and
the signal handler assumes it runs in that thread.

add some new linux AT_* flags

fix faccessat to support AT_EACCESS flag

this is another case of the kernel syscall failing to support flags
where it needs to, leading to horrible workarounds in userspace. this
time the workaround requires changing uid/gid, and that's not safe to
do in the current process. in the worst case, kernel resource limits
might prevent recovering the original values, and then there would be
no way to safely return. so, use the safe but horribly inefficient
alternative: forking. clone is used instead of fork to suppress
signals from the child.

fortunately this worst-case code is only needed when effective and
real ids mismatch, which mainly happens in suid programs.

collapse euidaccess to a call to faccessat

it turns out Linux is buggy for faccessat, just like fchmodat: the
kernel does not actually take a flags argument. so we're going to have
to emulate it there.

add prototypes for euidaccess/eaccess

add legacy euidaccess function and eaccess alias for it

this is mainly for ABI compat purposes.

make tdestroy allow null function pointer if no destructor is needed

this change is to align with a change in the glibc interface.

fix aliasing violations in tsearch functions

patch by nsz. the actual object the caller has storing the tree root
has type void *, so accessing it as struct node * is not valid.
instead, simply access the value, move it to a temporary of the
appropriate type and work from there, then move the result back.

protect against long double type mismatches (mainly powerpc for now)

check in configure to be polite (failing early if we're going to fail)
and in vfprintf.c since that is the point at which a mismatching type
would be extremely dangerous.

add legacy function valloc

it was already declared in stdlib.h, but not defined anywhere.

fix feature test macro logic for _BSD_SOURCE

in several places, _BSD_SOURCE was not even implying POSIX, resulting
in it being subtractive rather than additive (compared to the default
features).

add wcsftime_t alias

this is a nonstandard extension.

add missing c++ extern "C" wrapping to link.h

make fchdir, fchmod, fchown, and fstat support O_PATH file descriptors

on newer kernels, fchdir and fstat work anyway. this same fix should
be applied to any other syscalls that are similarly affected.

with this change, the current definitions of O_SEARCH and O_EXEC as
O_PATH are mostly conforming to POSIX requirements. the main remaining
issue is that O_NOFOLLOW has different semantics.

debloat code that depends on /proc/self/fd/%d with shared function

I intend to add more Linux workarounds that depend on using these
pathnames, and some of them will be in "syscall" functions that, from
an anti-bloat standpoint, should not depend on the whole snprintf
framework.

work around linux's lack of flags argument to fchmodat syscall

previously, the AT_SYMLINK_NOFOLLOW flag was ignored, giving
dangerously incorrect behavior -- the target of the symlink had its
modes changed to the modes (usually 0777) intended for the symlink).
this issue was amplified by the fact that musl provides lchmod, as a
wrapper for fchmodat, which some archival programs take as a sign that
symlink modes are supported and thus attempt to use.

emulating AT_SYMLINK_NOFOLLOW was a difficult problem, and I
originally believed it could not be solved, at least not without
depending on kernels newer than 3.5.x or so where O_PATH works halfway
well. however, it turns out that accessing O_PATH file descriptors via
their pseudo-symlink entries in /proc/self/fd works much better than
trying to use the fd directly, and works even on older kernels.
moreover, the kernel has permanently pegged these references to the
inode obtained by the O_PATH open, so there should not be race
conditions with the file being moved, deleted, replaced, etc.

move RPATH search after LD_LIBRARY_PATH search

this is the modern way, and the only way that makes any sense. glibc
has this complicated mechanism with RPATH and RUNPATH that controls
whether RPATH is processed before or after LD_LIBRARY_PATH, presumably
to support legacy binaries, but there is no compelling reason to
support this, and better behavior is obtained by just fixing the
search order.

provide useless 64-bit fcntl macros with _LARGEFILE64_SOURCE

this is all useless but part of the API, which is part of the
_GNU_SOURCE API, so something may need them.

if map_library has allocated a buffer for phdrs, free it on success too

this fixes an oversight in the previous commit.

improve error handling in map_library and support long phdrs

previously, errno could be meaningless when the caller wrote it to the
dlerror string or stderr. try to make it meaningful. also, fix
incorrect check for over-long program headers and instead actually
support them by allocating memory if needed.

fix uninitialized dyn variable in map_library

this can only happen for invalid library files, but they were not
detected reliably because the variable was uninitialized.

fix (deprecated) mktemp logic and update it to match other temp functions

the access function cannot be used to check for existence, because it
operates using real uid/gid rather than effective to determine
accessibility; this matters for the non-final path components.
instead, use stat. failure of stat is success if only the final
component is missing (ENOENT) and otherwise is failure.

remove (no longer useful) namespace-protected __mktemp symbol

make mkdtemp and mkstemp family leave template unchanged on fail

also refactor mkdtemp based on new shared temp code, removing
dependency on the deprecated mktemp, whose behavior made this logic
more difficult.

optimized memset asm for i386 and x86_64

the concept of both versions is the same; they differ only in details.
for long runs, they use "rep movsl" or "rep movsq", and for small
runs, they use a trick, writing from both ends towards the middle,
that reduces the number of branches needed. in addition, if memset is
called multiple times with the same length, all branches will be
predicted; there are no loops.

for larger runs, there are likely faster approaches than "rep", at
least on some cpu models. for 32-bit, it's unlikely that there is any
faster approach that does not require non-baseline instructions; doing
anything fancier would require inspecting cpu capabilities. for
64-bit, there may very well be faster versions that work on all
models; further optimization could be explored in the future.

with these changes, memset is anywhere between 50% faster and 6 times
faster, depending on the cpu model and the length and alignment of the
destination buffer.

work around gcc 4.8's generation of self-referential mem* functions at -O3

in pthread_getattr_np, use mremap rather than madvise to measure stack

the original motivation for this patch was that qemu (and possibly
other syscall emulators) nop out madvise, resulting in an infinite
loop. however, there is another benefit to this change: madvise may
actually undo an explicit madvise the application intended for its
stack, whereas the mremap operation is a true nop. the logic here is
that mremap must fail if it cannot resize the mapping in-place, and
the caller knows that it cannot resize in-place because it knows the
next page of virtual memory is already occupied.

fix theoretical out-of-bound access in dynamic linker

one of the arguments to memcmp may be shorter than the length l-3, and
memcmp is under no obligation not to access past the first byte that
differs. instead use strncmp which conveys the correct semantics. the
performance difference is negligible here and since the code is only
use for shared libc, both functions are already linked anyway.

prevent passing PT_INTERP name to dlopen from double-loading libc

the dev/inode for the main app and the dynamic linker ("interpreter")
are not available, so the subsequent checks don't work. in general we
don't want to make exact string matches to existing libraries prevent
loading new ones, since this breaks loading upgraded modules in
module-loading systems. so instead, special-case it.

the motivation for this fix is that calling dlopen on the names
returned by dl_iterate_phdr or walking the link map (obtained by
dlinfo) seem to be the only methods available to an application to
actually get a list of open dso handles.

add some sanity checks in dynamic loader code

reject elf files which are not ET_EXEC/ET_DYN type as bad exec format,
and reject ET_EXEC files when they cannot be loaded at the correct
address, since they are not relocatable at runtime. the main practical
benefit of this is to make dlopen of the main program fail rather than
producing an unsafe-to-use handle.

fix bug where read error was treated as success reading library headers

don't call null pointer if DT_INIT/DT_FINI are null

it's not clear to me why the linker even outputs these headers if they
are null, but apparently it does so. with the default startfiles, they
will never be null anyway, but this patch allows eliminating crti,
crtn, crtbegin, and crtend (leaving only crt1) if the toolchain is
using init_array/fini_array (or for a C-only, no-ctor environment).

add macros for new(ish) prctl commands

fix some prctl macros that were incorrectly copied into this file

use separate sigaction buffers for old and new data

in signal() it is needed since __sigaction uses restrict in parameters
and sharing the buffer is technically an aliasing error. do the same
for the syscall, as at least qemu-user does not handle it properly.

release notes for 0.9.12

add missing erfcl wrapper for archs where long double is plain double

fix semantically incorrect use of LC_GLOBAL_LOCALE

LC_GLOBAL_LOCALE refers to the global locale, controlled by setlocale,
not the thread-local locale in effect which these functions should be
using. neither LC_GLOBAL_LOCALE nor 0 has an argument to the *_l
functions has behavior defined by the standard, but 0 is a more
logical choice for requesting the callee to lookup the current locale.
in the future I may move the current locale lookup the the caller (the
non-_l-suffixed wrapper).

at this point, all of the locale logic is dummied out, so no harm was
done, but it should at least avoid misleading usage.

fix indention-with-spaces

reorder strftime to eliminate the incorrect indention level

this change is in preparation for possibly adding support for the
field width and padding specifiers added in POSIX 2008.

add wrapper headers, with warnings, for various incorrect names under sys

also add a warning to the existing sys/poll.h. the warning is absent
from sys/dir.h because it is actually providing a slightly different
API to the program, and thus just replacing the #include directive is
not a valid fix to programs using this one.

a few more fixes for unistd/sysconf feature reporting

report presence of ADV and MSG options in unistd.h and sysconf

report that posix_spawn is supported in unistd.h and sysconf

add ABI symbols for strtol family functions

these odd names are actually generated by mess in glibc's stdlib.h, so
any glibc-linked program using strtol needs them to run against musl.

make ldd report the libc/dynamic linker itself

fix computation of entry point and main app phdrs when invoking via ldso

entry point was wrong for PIE. e_entry was being treated as an
absolute value, whereas it's actually relative to the load address
(which is zero for non-PIE).

phdr pointer was wrong for non-PIE. e_phoff was being treated as
load-address-relative, whereas it's actually a file offset in the ELF
file. in any case, map_library was already computing it correctly, and
the incorrect code in __dynlink was overwriting it with junk.

fix powerpc build breakage from dynamic linker path search changes

new mostly-C crt1 implementation

the only immediate effect of this commit is enabling PIE support on
some archs that did not previously have any Scrt1.s, since the
existing asm files for crt1 override this C code. so some of the
crt_arch.h files committed are only there for the sake of documenting
what their archs "would do" if they used the new C-based crt1.

the expectation is that new archs should use this new system rather
than using heavy asm for crt1. aside from being easier and less
error-prone, it also ensures that PIE support is available immediately
(since Scrt1.o is generated from the same C source, using -fPIC)
rather than having to be added as an afterthought in the porting
process.

fix undefined strcpy call in inet_ntop

source and dest arguments for strcpy cannot overlap, so memmove must
be used here. the length is already known from the above loop.

make inet_ntop format v4-mapped ipv6 addresses properly

based on a patch by orc. POSIX actually fails to specify the format of
the ntop conversion; presumably, any output that will correctly
round-trip back via the (well-specified) pton operation is acceptable.
the new behavior is much more convenient than the old, however.

this patch also affects getnameinfo, which is implemented in terms of
inet_ntop and which is the preferred interface for performing this
conversion.

I've also removed some inexplicable cruft (filling the buffer with 'x'
before doing anything) whose origin I was unable to track down.

do not include math modules in the default -O3 optimization set

it's not clear that -O3 helps them, and gcc seems to have floating
point optimization bugs that introduce additional failures when -O3 is
used on some of these files.

fix incorrect type for new si_call_addr in siginfo_t

apparently the original kernel commit's i386 version of siginfo.h
defined this field as unsigned int, but the asm-generic file always
had void *. unsigned int is obviously not a suitable type for an
address, in a non-arch-specific file, and glibc also has void * here,
so I think void * is the right type for it.

also fix redundant type specifiers.

add protocol families PF_IB and PF_VSOCK to socket.h

linux commit 8d36eb01da5d371feffa280e501377b5c450f5a5 (2013-05-29)
added PF_IB for InfiniBand

linux commit d021c344051af91f42c5ba9fdedc176740cbd238 (2013-02-06)
added PF_VSOCK for VMware sockets

update siginfo according to linux headers

linux commit a0727e8ce513fe6890416da960181ceb10fbfae6 (2012-04-12)
added siginfo fields for SIGSYS (seccomp uses it)

linux commit ad5fa913991e9e0f122b021e882b0d50051fbdbc (2009-09-16)
added siginfo field and si_code values for SIGBUS (hwpoison signal)

rework langinfo code for ABI compat and for use by time code

update strxfrm/wcsxfrm for future LC_COLLATE support and ABI compat

add ABI compat aliases for a number of locale_t functions

add PTRACE_PEEKSIGINFO to ptrace.h
added in linux-v3.10 commit 84c751bd4aebbaae995fe32279d3dba48327bad4
using stdint.h types for the new ptrace_peeksiginfo_args struct

add if_ether.h constants ETH_P_802_3_MIN and ETH_P_BATMAN
see linux commits 4f99ad51292078cc47343c17d3870764588cff73 and
e5c5d22e8dcf7c2d430336cbf8e180bd38e8daf1

add CLOCK_TAI (and CLOCK_SGI_CYCLE) clock ids to time.h
added in linux-v3.10 commit 1ff3c9677bff7e468e0c487d0ffefe4e901d33f4

remove TCP_COOKIE_TRANSACTIONS from tcp.h
removed in linux-v3.10 in commit 1a2c6181c4a1922021b4d7df373bba612c3e5f04

add SO_SELECT_ERR_QUEUE to socket.h
introduced in linux-v3.10 commit 7d4c04fc170087119727119074e72445f2bb192b

prepare strcoll/wcscoll for LC_COLLATE support and add ABI symbols

add _l versions of strtod family functions, purely as aliases

this is a cheat since the _l versions take an extra argument, but
since these functions are only here for ABI purposes, it doesn't
really matter as long as the ABI matches. if the non-__-prefixed
versions are eventually made public, they should proabably be real
functions rather than hacks like this.

add __wcsftime_l symbol

unlike the strftime commit, this one is purely an ABI compatibility
issue. the previous version of the code would have worked just as well
with LC_TIME once LC_TIME support is added.

move strftime_l into strftime.c and add __-prefixed version

the latter is both for ABI purposes, and to facilitate eventually
adding LC_TIME support. it's also nice to eliminate an extra source
file.

make getaddrinfo with AF_UNSPEC and null host return both IPv4 and v6

based on a patch by orc, with indexing and flow control cleaned up a
little bit. this code is all going to be replaced at some point in the
near future.

support STB_GNU_UNIQUE symbol bindings in dynamic linker

these are needed for some C++ library binaries including most builds
of libstdc++. I'm not entirely clear on the rationale. this patch does
not implement any special semantics for them, but as far as I can
tell, no special treatment is needed in correctly-linked programs;
this binding seems to exist only for catching incorrectly-linked
programs.

move the dynamic linker's jmp_buf from static to automatic storage

this more than compensates for the size increase of jmp_buf, and
greatly reduces bss/data size on archs with huge jmp_buf.

change jmp_buf to share an underlying type and struct tag with sigjmp_buf

this is necessary to meet the C++ ABI target. alternatives were
considered to avoid the size increase for non-sig jmp_buf objects, but
they seemed to have worse properties. moreover, the relative size
increase is only extreme on x86[_64]; one way of interpreting this is
that, if the size increase from this patch makes jmp_buf use too much
memory, then the program was already using too much memory when built
for non-x86 archs.

remove redundant check in memalign

the case where mem was already aligned is handled earlier in the
function now.

fix heap corruption bug in memalign

this bug was caught by the new footer-corruption check in realloc and
free.

if the block returned by malloc was already aligned to the desired
alignment, memalign's logic to split off the misaligned head was
incorrect; rather than writing to a point inside the allocated block,
it was overwriting the footer of the previous block on the heap with
the value 1 (length 0 plus an in-use flag).

fortunately, the impact of this bug was fairly low. (this is probably
why it was not caught sooner.) due to the way the heap works, malloc
will never return a block whose previous block is free. (doing so would
be harmful because it would increase fragmentation with no benefit.)
the footer is actually not needed for in-use blocks, except that its
in-use bit needs to remain set so that it does not get merged with
free blocks, so there was no harm in it being set to 1 instead of the
correct value.

however, there is one case where this bug could have had an impact: in
multi-threaded programs, if another thread freed the previous block
after memalign's call to malloc returned, but before memalign
overwrote the previous block's footer, the resulting block in the free
list could be left in a corrupt state. I have not analyzed the impact
of this bad state and whether it could lead to more serious
malfunction.