* parse IPv4 dotted-decimal correctly (without strtoul, no leading zeros)
* disallow single leading ':' in IPv6 address
* allow at most 4 hex digits in IPv6 address (according to RFC 2373)
* have enough hex fields in IPv4 mapped IPv6 address
* disallow leading zeros in IPv4 mapped IPv6 address

* allow at most 4 parts
* bounds check the parts correctly
* disallow leading whitespace and sign
* check the address family before falling back to IPv6

despite being practically deprecated, these functions are still part
of the standard and thus cannot reside in a file that also contains
namespace pollution. this reverts some of the changes made in commit
e40f48a4.

fcntl.h: AT_* is not a reserved namespace so extensions cannot be
exposed by default.

langinfo.h: YESSTR and NOSTR were removed from the standard.

limits.h: NL_NMAX was removed from the standard.

signal.h: the conditional for NSIG was wrongly checking _XOPEN_SOURCE
rather than _BSD_SOURCE. this was purely a mistake; it doesn't even
match the commit message from the commit that added it.

in the case of input that does not match the expected form, the
correct return value is 0, not -1.

as usual, this is needed to avoid fd leaks. as a better solution, the
use of fds could possibly be replaced with mmap and a futex.

this fixes an issue reported by Daniel Thau whereby faccessat with the
AT_EACCESS flag did not work in cases where the process is running
suid or sgid but without root privileges. per POSIX, when the process
does not have "appropriate privileges", setuid changes the euid, not
the real uid, and the target uid must be equal to the current real or
saved uid; if this condition is not met, EPERM results. this caused
the faccessat child process to fail.

using the setreuid syscall rather than setuid works. POSIX leaves it
unspecified whether setreuid can set the real user id to the effective
user id on processes without "appropriate privileges", but Linux
allows this; if it's not allowed, there would be no way for this
function to work.

based on patch by Michael Forney. at the same time, I've changed the
if branch to be more clear, avoiding the comma operator.

the underlying issue is that Linux always returns ERANGE when size is
too short, even when it's zero, rather than returning EINVAL for the
special case of zero as required by POSIX.

the issue is described in commits 1e5eb735
and ffd8ac2d

this makes acosh slightly more precise around 1.0 on i386

sizeof had incorrect argument in a few places, the size was always
large enough so the issue was not critical.

add missing va_end and remove some unnecessary code.

there is no reason to check the return value for setting errno, since
brk never returns errors, only the new value of the brk (which may be
the same as the old, or otherwise differ from the requested brk, on
failure).

it may be beneficial to eventually just eliminate this file and make
the syscalls inline in malloc.c.

I wrongly assumed the brk syscall would set errno, but on failure it
returns the old value of the brk rather than an error code.

erfl had some superflous code left around after the last erf cleanup.
the issue was reported by Alexander Monakov

the issue was reported by Alexander Monakov

the affected branch only applies for DSOs that lack standard hash
table and only have the GNU hash table present.

the va_arg call for the argv[]-terminating null pointer was missing,
so this pointer was being wrongly used as the environment pointer.

issue reported by Timo Teräs. proposed patch slightly modified to
simplify the resulting code.

bug report and patch by Michael Forney. the terminating null pointer
at the end of the gr_mem array was overwriting the beginning of the
string data, causing the gr_name member to always be a zero-length
string.

issue reported by Michael Forney:

"If wn becomes 0 after processing a chunk of 4, mbsrtowcs currently
continues on, wrapping wn around to -1, causing the rest of the string
to be processed.

This resulted in buffer overruns if there was only space in ws for wn
wide characters."

the original patch submitted added an additional check for !wn after
the loop; to avoid extra branching, I instead just changed the wn>=4
check to wn>=5 to ensure that at least one slot remains after the
word-at-a-time loop runs. this should not slow down the tail
processing on real-world usage, since an extra slot that can't be
processed in the word-at-a-time loop is needed for the null
termination anyway.

This is a change in ISO C11 annex F (F.10.11p1), comparision macros
can't round their arguments to their semantic type when the evaluation
format has wider range and precision. (ie. they must be consistent with
the builtin relational operators)

somehow the range 335-339 was missed when updating the file.

atomic store was lacking a barrier, which was fine for legacy arm with
no real smp and kernel-emulated cas, but unsuitable for more modern
systems. the kernel provides another "kuser" function, at 0xffff0fa0,
which could be used for the barrier, but using that would drop support
for kernels 2.6.12 through 2.6.14 unless an extra conditional were
added to check for barrier availability. just using the barrier in the
kernel cas is easier, and, based on my reading of the assembly code in
the kernel, does not appear to be significantly slower.

at the same time, other atomic operations are adapted to call the
kernel cas function directly rather than using a_cas; due to small
differences in their interface contracts, this makes the generated
code much simpler.

if a multithreaded program became non-multithreaded (i.e. all other
threads exited) while one thread held an internal lock, the remaining
thread would fail to release the lock. the the program then became
multithreaded again at a later time, any further attempts to obtain
the lock would deadlock permanently.

the underlying cause is that the value of libc.threads_minus_1 at
unlock time might not match the value at lock time. one solution would
be returning a flag to the caller indicating whether the lock was
taken and needs to be unlocked, but there is a simpler solution: using
the lock itself as such a flag.

note that this flag is not needed anyway for correctness; if the lock
is not held, the unlock code is harmless. however, the memory
synchronization properties associated with a_store are costly on some
archs, so it's best to avoid executing the unlock code when it is
unnecessary.

this is the number of realtime signals available, not the maximum
signal number or total number of signals.

they were leaving junk in the upper bits.

this was resulting in crashes in posix_spawn on mips, and would have
affected applications calling clone too. since the prototype for
__clone has it as a variadic function, it may not assume that 16($sp)
is writable for use in making the syscall. instead, it needs to
allocate additional stack space, and then adjust the stack pointer
back in both of the code paths for the parent process/thread.

These constants are not specified by POSIX, but they are in the reserved
namespace, glibc and bsd systems seem to provide them as well.
(Note that POSIX specifies -NZERO and NZERO-1 to be the limits, but
PRIO_MAX equals NZERO)