despite being marked legacy, this was specified by SUSv3 as part of
the XSI option; only the most recent version of the standard dropped
it. reportedly there's actual code using it.

* 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.

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.

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.

CLONE_PARENT is not necessary (CLONE_THREAD provides all the useful
parts of it) and Linux treats CLONE_PARENT as an error in certain
situations, without noticing that it would be a no-op due to
CLONE_THREAD. this error case prevents, for example, use of a
multi-threaded init process and certain usages with containers.

PAGE_SIZE was hardcoded to 4096, which is historically what most
systems use, but on several archs it is a kernel config parameter,
user space can only know it at execution time from the aux vector.

PAGE_SIZE and PAGESIZE are not defined on archs where page size is
a runtime parameter, applications should use sysconf(_SC_PAGE_SIZE)
to query it. Internally libc code defines PAGE_SIZE to libc.page_size,
which is set to aux[AT_PAGESZ] in __init_libc and early in __dynlink
as well. (Note that libc.page_size can be accessed without GOT, ie.
before relocations are done)

Some fpathconf settings are hardcoded to 4096, these should be actually
queried from the filesystem using statfs.

the value of MQ_PRIO_MAX does not fit, so it needs to use OFLOW.

unlike other archs, the mips version of clone was not doing anything
to align the stack pointer. this seems to have been the cause for some
SIGBUS crashes that were observed in posix_spawn.

the underlying problem was not incorrect sign extension (fixed in the
previous commit to this file by nsz) but that code that treats "long"
as 32-bit was copied blindly from i386 to x86_64.

now lrintl is identical to llrintl on x86_64, as it should be.

if fopen fails for a reason other than ENOENT, we must assume the
intent is that the path file be used. failure may be due to
misconfiguration or intentional resource-exhaustion attack (against
suid programs), in which case falling back to loading libraries from
an unintended path could be dangerous.

gcc did not always drop excess precision according to c99 at assignments
before version 4.5 even if -std=c99 was requested which caused badly
broken mathematical functions on i386 when FLT_EVAL_METHOD!=0

but STRICT_ASSIGN was not used consistently and it is worked around for
old compilers with -ffloat-store so it is no longer needed

the new convention is to get the compiler respect c99 semantics and when
excess precision is not harmful use float_t or double_t or to specialize
code using FLT_EVAL_METHOD