fix linked list corruption in flockfile lists

commit 5345c9b884e7c4e73eb2c8bb83b8d0df20f95afb added a linked list to
track the FILE streams currently locked (via flockfile) by a thread.
due to a failure to fully link newly added members, removal from the
list could leave behind references which could later result in writes
to already-freed memory and possibly other memory corruption.

implicit stdio locking was unaffected; the list is only used in
conjunction with explicit flockfile locking.

this bug was not present in any releases; it was introduced and fixed
during the same release cycle.

patch by Timo Teräs, who discovered and tracked down the bug.

math: fix exp10 not to raise invalid exception on NaN

This was not caught earlier because gcc incorrectly generates quiet
relational operators that never raise exceptions.

fix overflow corner case in strtoul-family functions

incorrect behavior occurred only in cases where the input overflows
unsigned long long, not just the (possibly lower) range limit for the
result type. in this case, processing of the '-' sign character was
not suppressed, and the function returned a value of 1 despite setting
errno to ERANGE.

rewrite the regex pattern parser in regcomp

The new code is a bit simpler and the generated code is about 1KB
smaller (on i386). The basic design was kept including internal
interfaces, TNFA generation was not touched.

The old tre parser had various issues:

[^aa-z]
negated overlapping ranges in a bracket expression were handled
incorrectly (eg [^aa-z] was handled as [^a] instead of [^a-z])

a{,2}
missing lower bound in a counted repetition should be an error,
but it was accepted with broken semantics: a{,2} was treated as
a{0,3}, the new parser rejects it

a{999,}
large min count was not rejected (a{5000,} failed with REG_ESPACE
due to reaching a stack limit), the new parser enforces the
RE_DUP_MAX limit

\xff
regcomp used to accept a pattern with illegal sequences in it
(treated them as empty expression so p\xffq matched pq) the new
parser rejects such patterns with REG_BADPAT or REG_ERANGE

[^b-fD-H] with REG_ICASE
old parser turned this into [^b-fB-F] because of the negated
overlapping range issue (see above), the new parser treats it
as [^b-hB-H], POSIX seems to require [^d-fD-F], but practical
implementations do case-folding first and negate the character
set later instead of the other way around. (Supporting the posix
way efficiently would require significant changes so it was left
as is, it is unclear if any application actually expects the
posix behaviour, this issue is raised on the austingroup tracker:
http://austingroupbugs.net/view.php?id=872 ).

another case-insensitive matching issue is that unicode case
folding rules can group more than two characters together while
towupper and towlower can only work for a pair of upper and
lower case characters, this is a limitation of POSIX so it is
not fixed.

invalid bracket and brace expressions may return different error
codes now (REG_ERANGE instead of REG_EBRACK or REG_BADBR instead
of REG_EBRACE) otherwise the new parser should be compatible with
the old one.

regcomp should be able to handle arbitrary pattern input if the
pattern length is limited, the only exception is the use of large
repetition counts (eg. (a{255}){255}) which require exp amount
of memory and there is no easy workaround.

fix C++ incompatibility in i386 definition of max_align_t

the C11 _Alignas keyword is not present in C++, and despite it being
in the reserved namespace and thus reasonable to support even in
non-C11 modes, compilers seem to fail to support it.

add _DEFAULT_SOURCE feature profile as an alias for _BSD_SOURCE

as a result of commit ab8f6a6e42ff893041f7545a23e6d6a0edde07fb, this
definition is now equivalent to the actual "default profile" which
appears immediately below in features.h, and which defines both
_BSD_SOURCE and _XOPEN_SOURCE.

the intent of providing a _DEFAULT_SOURCE, which glibc also now
provides, is to give applications a way to "get back" the default
feature profile when it was lost either by compiler flags that inhibit
it (such as -std=c99) or by library-provided predefined macros (such
as -D_POSIX_C_SOURCE=200809L) which may inhibit exposure of features
that were otherwise visible by default and which the application may
need. without _DEFAULT_SOURCE, the application had encode knowledge of
a particular libc's defaults, and such knowledge was fragile and
subject to bitrot.

eventually the names _GNU_SOURCE and _BSD_SOURCE should be phased out
in favor of the more-descriptive and more-accurate _ALL_SOURCE and
_DEFAULT_SOURCE, leaving the old names as aliases but using the new
ones internally. however this is a more invasive change that would
require extensive regression testing, so it is deferred.

fix _ALL_SOURCE logic to avoid possible redefinition of _GNU_SOURCE

this could be an error if _GNU_SOURCE was already defined differently
by the application.

fix places where _BSD_SOURCE failed to yield a superset of _XOPEN_SOURCE

the vast majority of these failures seem to have been oversights at
the time _BSD_SOURCE was added, or perhaps shortly afterward. the one
which may have had some reason behind it is omission of setpgrp from
the _BSD_SOURCE feature profile, since the standard setpgrp interface
conflicts with a legacy (pre-POSIX) BSD interface by the same name.
however, such omission is not aligned with our general policy in this
area (for example, handling of similar _GNU_SOURCE cases) and should
not be preserved.

fix exp10l.c to include float.h

the previous commit was a no op in exp10l because LDBL_* macros
were implicitly 0 (the preprocessor does not warn about undefined
symbols).

prune math code on archs with binary64 long double

__polevll, __p1evll and exp10l were provided on archs when long double
is the same as double. The first two were completely unused and exp10l
can be a wrapper around exp10.

add new F_OFD_* macros to fcntl.h (open file description locks)

open file description locks are inherited across fork and only auto
dropped after the last fd of the file description is closed, they can be
used to synchronize between threads that open separate file descriptions
for the same file.

new in linux 3.15 commit 0d3f7a2dd2f5cf9642982515e020c1aee2cf7af6

add C11 thread creation and related thread functions

based on patch by Jens Gustedt.

the main difficulty here is handling the difference between start
function signatures and thread return types for C11 threads versus
POSIX threads. pointers to void are assumed to be able to represent
faithfully all values of int. the function pointer for the thread
start function is cast to an incorrect type for passing through
pthread_create, but is cast back to its correct type before calling so
that the behavior of the call is well-defined.

changes to the existing threads implementation were kept minimal to
reduce the risk of regressions, and duplication of code that carries
implementation-specific assumptions was avoided for ease and safety of
future maintenance.

add C11 condition variable functions

Because of the clear separation for private pthread_cond_t these
interfaces are quite simple and direct.

add C11 mutex functions

add C11 thread functions operating on tss_t and once_flag

These all have POSIX equivalents, but aside from tss_get, they all
have minor changes to the signature or return value and thus need to
exist as separate functions.

add threads.h and needed per-arch types for mtx_t and cnd_t

based on patch by Jens Gustedt.

mtx_t and cnd_t are defined in such a way that they are formally
"compatible types" with pthread_mutex_t and pthread_cond_t,
respectively, when accessed from a different translation unit. this
makes it possible to implement the C11 functions using the pthread
functions (which will dereference them with the pthread types) without
having to use the same types, which would necessitate either namespace
violations (exposing pthread type names in threads.h) or incompatible
changes to the C++ name mangling ABI for the pthread types.

for the rest of the types, things are much simpler; using identical
types is possible without any namespace considerations.

use weak symbols for the POSIX functions that will be used by C threads

The intent of this is to avoid name space pollution of the C threads
implementation.

This has two sides to it. First we have to provide symbols that wouldn't
pollute the name space for the C threads implementation. Second we have
to clean up some internal uses of POSIX functions such that they don't
implicitly drag in such symbols.

add C11 timespec_get function, with associated time.h changes for C11

based on patch by Jens Gustedt for inclusion with C11 threads
implementation, but committed separately since it's independent of
threads.

fix non-static dummy function that slipped in with locale implementation

fix macros for LFS *64_t types in sys/stat.h, sys/types.h, glob.h

there is no blksize64_t (blksize_t is always long) but there are
fsblkcnt64_t and fsfilcnt64_t types in sys/stat.h and sys/types.h.
and glob.h missed glob64_t.

add missing legacy LFS *64 symbol aliases

versionsort64, aio*64 and lio*64 symbols were missing, they are
only needed for glibc ABI compatibility, on the source level
dirent.h and aio.h already redirect them.

fix memory leak in regexec when input contains illegal sequence

fix off-by-one in bounds check in fpathconf

this error resulted in an out-of-bounds read, as opposed to a reported
error, when calling the function with an argument one greater than the
max valid index.

fix potential read past end of buffer in getnameinfo service name lookup

if the loop stopped due to reaching the end of the string, the
subsequent increment could possibly move the position one past the end
of the buffer. no further writes happen, the reads cannot fault anyway
unless the stack completely lacks any zero bytes, and reading junk
should not yield an incorrect result from the function either.
nonetheless the code was wrong and needs to be fixed.

remove incorrect and useless check in network service name lookup code

the condition was probably intended to be !*p rather than !p, but
neither is needed here. the subsequent code naturally handles the case
where it's already at end of string.

fix case mapping for U+00DF (ß)

U+00DF ('ß') has had an uppercase form (U+1E9E) available since
Unicode 5.1, but Unicode lacks the case mappings for it due to
stability policy. when I added support for the new character in commit
1a63a9fc30e7a1f1239e3cedcb5041e5ec1c5351, I omitted the mapping in the
lowercase-to-uppercase direction. this choice was not based on any
actual information, only assumptions.

this commit adds bidirectional case mappings between U+00DF and
U+1E9E, and removes the special-case hack that allowed U+00DF to be
identified as lowecase despite lacking a mapping. aside from strong
evidence that this is the "right" behavior for real-world usage of
these characters, several factors informed this decision:

- the other "potentially correct" mapping, to "SS", is not
  representable in the C case-mapping system anyway.

- leaving one letter in lowercase form when transforming a string to
  uppercase is obviously wrong.

- having a character which is nominally lowercase but which is fixed
  under case mapping violates reasonable invariants.

make non-waiting paths of sem_[timed]wait and pthread_join cancelable

per POSIX these functions are both cancellation points, so they must
act on any cancellation request which is pending prior to the call.
previously, only the code path where actual waiting took place could
act on cancellation.

remove an extra layer of buffer copying in getnameinfo reverse dns

the outer getnameinfo function already has a properly-sized temporary
buffer for storing the reverse dns (ptr) result. there is no reason
for the callback to use a secondary buffer and copy it on success, and
doing so potentially expanded the impact of the dn_expand bug that was
fixed in commit 49d2c8c6bcf8c926e52c7f510033b6adc31355f5.

this change reduces the code size by a small amount, and also reduces
the run-time stack space requirements by about 256 bytes.

fix multiple stdio functions' behavior on zero-length operations

previously, fgets, fputs, fread, and fwrite completely omitted locking
and access to the FILE object when their arguments yielded a zero
length read or write operation independent of the FILE state. this
optimization was invalid; it wrongly skipped marking the stream as
byte-oriented (a C conformance bug) and exposed observably missing
synchronization (a POSIX conformance bug) where one of these functions
could wrongly complete despite another thread provably holding the
lock.

suppress null termination when fgets reads EOF with no data

the C standard requires that "the contents of the array remain
unchanged" in this case.

this patch also changes the behavior on read errors, but in that case
"the array contents are indeterminate", so the application cannot
inspect them anyway.

fix dn_expand empty name handling and offsets to 0

Empty name was rejected in dn_expand since commit
56b57f37a46dab432247bf29d96fcb11fbd02a6d
which is a regression as reported by Natanael Copa.

Furthermore if an offset pointer in a compressed name
pointed to a terminating 0 byte (instead of a label)
the returned name was not null terminated.

add static_assert and hide noreturn, alignas, alignof from C++

add static_assert and protect the other new C11 keyword macros
with #ifndef __cplusplus so they don't conflict with C++ keywords.

add C11 floating-point characteristic macros to float.h

C11 introduced *_DECIMAL_DIG and *_HAS_SUBNORM macros.

add malloc_usable_size function and non-stub malloc.h

this function is needed for some important practical applications of
ABI compatibility, and may be useful for supporting some non-portable
software at the source level too.

I was hesitant to add a function which imposes any constraints on
malloc internals; however, it turns out that any malloc implementation
which has realloc must already have an efficient way to determine the
size of existing allocations, so no additional constraint is imposed.

for now, some internal malloc definitions are duplicated in the new
source file. if/when malloc is refactored to put them in a shared
internal header file, these could be removed.

since malloc_usable_size is conventionally declared in malloc.h, the
empty stub version of this file was no longer suitable. it's updated
to provide the standard allocator functions, nonstandard ones (even if
stdlib.h would not expose them based on the feature test macros in
effect), and any malloc-extension functions provided (currently, only
malloc_usable_size).

refrain from spinning on locks when there is already a waiter

if there is already a waiter for a lock, spinning on the lock is
essentially an attempt to steal it from whichever waiter would obtain
it via any priority rules in place, and is therefore undesirable. in
the current implementation, there is always an inherent race window at
unlock during which a newly-arriving thread may steal the lock from
the existing waiters, but we should aim to keep this window minimal
rather than enlarging it.

spin before waiting on futex in mutex and rwlock lock operations

spin in sem_[timed]wait before performing futex wait

empirically, this increases the maximum rate of wait/post operations
between two threads by 20-150 times on machines I tested, including
x86 and arm. conceptually, it makes sense to do some spinning because
semaphores are intended to be usable as a notification mechanism
between threads, not just as locks, and low-latency notification is a
valuable property to have.

fix build error on arm due to new a_spin code

this was broken by commit ea818ea8340c13742a4f41e6077f732291aea4bc.

sanitize number of spins in userspace before futex wait

the previous spin limit of 10000 was utterly unreasonable.
empirically, it could consume up to 200000 cycles, whereas a failed
futex wait (EAGAIN) typically takes 1000 cycles or less, and even a
true wait/wake round seems much less expensive.

the new counts (100 for general wait, 200 in barrier) were simply
chosen to be in the range of what's reasonable without having adverse
effects on casual micro-benchmark tests I have been running. they may
still be too high, from a standpoint of not wasting cpu cycles, but at
least they're a lot better than before. rigorous testing across
different archs and cpu models should be performed at some point to
determine whether further adjustments should be made.

add working a_spin() atomic for non-x86 targets

conceptually, a_spin needs to be at least a compiler barrier, so the
compiler will not optimize out loops (and the load on each iteration)
while spinning. it should also be a memory barrier, or the spinning
thread might keep spinning without noticing stores from other threads,
thus delaying for longer than it should.

ideally, an optimal a_spin implementation that avoids unnecessary
cache/memory contention should be chosen for each arch, but for now,
the easiest thing is to perform a useless a_cas on the calling
thread's stack.

fix false ownership of stdio FILEs due to tid reuse

this is analogous commit fffc5cda10e0c5c910b40f7be0d4fa4e15bb3f48
which fixed the corresponding issue for mutexes.

the robust list can't be used here because the locks do not share a
common layout with mutexes. at some point it may make sense to simply
incorporate a mutex object into the FILE structure and use it, but
that would be a much more invasive change, and it doesn't mesh well
with the current design that uses a simpler code path for internal
locking and pulls in the recursive-mutex-like code when the flockfile
API is used explicitly.

fix fallback checks for kernels without private futex support

for unknown syscall commands, the kernel produces ENOSYS, not EINVAL.

fix use of uninitialized memory with application-provided thread stacks

the subsequent code in pthread_create and the code which copies TLS
initialization images to the new thread's TLS space assume that the
memory provided to them is zero-initialized, which is true when it's
obtained by pthread_create using mmap. however, when the caller
provides a stack using pthread_attr_setstack, pthread_create cannot
make any assumptions about the contents. simply zero-filling the
relevant memory in this case is the simplest and safest fix.

add max_align_t definition for C11 and C++11

unfortunately this needs to be able to vary by arch, because of a huge
mess GCC made: the GCC definition, which became the ABI, depends on
quirks in GCC's definition of __alignof__, which does not match the
formal alignment of the type.

GCC's __alignof__ unexpectedly exposes the an implementation detail,
its "preferred alignment" for the type, rather than the formal/ABI
alignment of the type, which it only actually uses in structures. on
most archs the two values are the same, but on some (at least i386)
the preferred alignment is greater than the ABI alignment.

I considered using _Alignas(8) unconditionally, but on at least one
arch (or1k), the alignment of max_align_t with GCC's definition is
only 4 (even the "preferred alignment" for these types is only 4).

further simplify and optimize new cond var

the main idea of the changes made is to have waiters wait directly on
the "barrier" lock that was used to prevent them from making forward
progress too early rather than first waiting on the atomic state value
and then attempting to lock the barrier.

in addition, adjustments to the mutex waiter count are optimized.
previously, each waking waiter decremented the count (unless it was
the first) then immediately incremented it again for the next waiter
(unless it was the last). this was a roundabout was of achieving the
equivalent of incrementing it once for the first waiter and
decrementing it once for the last.

simplify and improve new cond var implementation

previously, wake order could be unpredictable: if a waiter happened to
leave its futex wait on the state early, e.g. due to EAGAIN while
restarting after a signal handler, it could acquire the mutex out of
turn. handling this required ugly O(n) list walking in the unwait
function and accounting to remove waiters that already woke from the
list.

with the new changes, the "barrier" locks in each waiter node are only
unlocked in turn. in addition to simplifying the code, this seems to
improve performance slightly, probably by reducing the number of
accesses threads make to each other's stacks.

as an additional benefit, unrecoverable mutex re-locking errors
(mainly ENOTRECOVERABLE for robust mutexes) no longer need to be
handled with deadlock; they can be reported to the caller, since the
unlocking sequence makes it unnecessary to rely on the mutex to
synchronize access to the waiter list.

redesign cond var implementation to fix multiple issues

the immediate issue that was reported by Jens Gustedt and needed to be
fixed was corruption of the cv/mutex waiter states when switching to
using a new mutex with the cv after all waiters were unblocked but
before they finished returning from the wait function.

self-synchronized destruction was also handled poorly and may have had
race conditions. and the use of sequence numbers for waking waiters
admitted a theoretical missed-wakeup if the sequence number wrapped
through the full 32-bit space.

the new implementation is largely documented in the comments in the
source. the basic principle is to use linked lists initially attached
to the cv object, but detachable on signal/broadcast, made up of nodes
residing in automatic storage (stack) on the threads that are waiting.
this eliminates the need for waiters to access the cv object after
they are signaled, and allows us to limit wakeup to one waiter at a
time during broadcasts even when futex requeue cannot be used.

performance is also greatly improved, roughly double some tests.

basically nothing is changed in the process-shared cond var case,
where this implementation does not work, since processes do not have
access to one another's local storage.

fix possible failure-to-wake deadlock with robust mutexes

when the kernel is responsible for waking waiters on a robust mutex
whose owner died, it does not have a waiters count available and must
rely entirely on the waiter bit of the lock value.

normally, this bit is only set by newly arriving waiters, so it will
be clear if no new waiters arrived after the current owner obtained
the lock, even if there are other waiters present. leaving it clear is
desirable because it allows timed-lock operations to remove themselves
as waiters and avoid causing unnecessary futex wake syscalls. however,
for process-shared robust mutexes, we need to set the bit whenever
there are existing waiters so that the kernel will know to wake them.

for non-process-shared robust mutexes, the wake happens in userspace
and can look at the waiters count, so the bit does not need to be set
in the non-process-shared case.

make pointers used in robust list volatile

when manipulating the robust list, the order of stores matters,
because the code may be asynchronously interrupted by a fatal signal
and the kernel will then access the robust list in what is essentially
an async-signal context.

previously, aliasing considerations made it seem unlikely that a
compiler could reorder the stores, but proving that they could not be
reordered incorrectly would have been extremely difficult. instead
I've opted to make all the pointers used as part of the robust list,
including those in the robust list head and in the individual mutexes,
volatile.

in addition, the format of the robust list has been changed to point
back to the head at the end, rather than ending with a null pointer.
this is to match the documented kernel robust list ABI. the null
pointer, which was previously used, only worked because faults during
access terminate the robust list processing.

fix robust mutex unrecoverable status, and related clean-up

a robust mutex should not enter the unrecoverable status until it's
unlocked without marking it consistent. previously, flag 8 in the type
was used as an indication of unrecoverable, but only honored after
successful locking; this resulted in a race window where the
unrecoverable mutex could appear to a second thread as locked/busy
again while the first thread was in the process of observing it as
unrecoverable.

now, flag 8 is used to mean that the mutex is in the process of being
recovered, but not yet marked consistent. the flag only takes effect
in pthread_mutex_unlock, where it causes the value 0x40000000 (owner
dead flag, with old owner tid 0, an otherwise impossible state) to be
stored in the lock. subsequent lock attempts will interpret this state
as unrecoverable.

fix false ownership of mutexes due to tid reuse, using robust list

per the resolution of Austin Group issue 755, the POSIX requirement
that ownership be enforced for recursive and error-checking mutexes
does not allow a random new thread to acquire ownership of an orphaned
mutex just because it happened to be assigned the same tid as the
original owner that exited with the mutex locked.

one possible fix for this issue would be to disallow the kernel thread
to terminate when it exited with mutexes held, permanently reserving
the tid against reuse. however, this does not solve the problem for
process-shared mutexes where lifetime cannot be controlled, so it was
not used.

the alternate approach I've taken is to reuse the robust mutex system
for non-robust recursive and error-checking mutexes. when a thread
exits, the kernel (or the new userspace robust-list code added in
commit b092f1c5fa9c048e12d002c7b972df5ecbe96d1d) will set the
owner-died bit for these orphaned mutexes, but since the mutex-type is
not robust, pthread_mutex_trylock will not allow a new owner to
acquire them. instead, they remain in a state of being permanently
locked, as desired.

optimize locking against vm changes for mmap/munmap

the whole point of this locking is to prevent munmap, or mmap with
MAP_FIXED, from deallocating virtual addresses, or changing the
backing a given virtual address refers to, during certain race windows
involving self-synchronized unmapping or destruction of pthread
synchronization objects. there is no need for exclusion in the other
direction, so it suffices to take the lock momentarily and release it
before making the syscall, rather than holding it across the syscall.

enable private futex for process-local robust mutexes

the kernel always uses non-private wake when walking the robust list
when a thread or process exits, so it's not able to wake waiters
listening with the private futex flag. this problem is solved by doing
the equivalent in userspace as the last step of pthread_exit.

care is taken to remove mutexes from the robust list before unlocking
them so that the kernel will not attempt to access them again,
possibly after another thread locks them. this removal code can treat
the list as singly-linked, since no further code which would add or
remove items is able to run at this point. moreover, the pending
pointer is not needed since the mutexes being unlocked are all
process-local; in the case of asynchronous process termination, they
all cease to exist.

since a process-local robust mutex cannot come into existence without
a call to pthread_mutexattr_setrobust in the same process, the code
for userspace robust list processing is put in that source file, and
a weak alias to a dummy function is used to avoid pulling in this
bloat as part of pthread_exit in static-linked programs.

make futex operations use private-futex mode when possible

private-futex uses the virtual address of the futex int directly as
the hash key rather than requiring the kernel to resolve the address
to an underlying backing for the mapping in which it lies. for certain
usage patterns it improves performance significantly.

in many places, the code using futex __wake and __wait operations was
already passing a correct fixed zero or nonzero flag for the priv
argument, so no change was needed at the site of the call, only in the
__wake and __wait functions themselves. in other places, especially
where the process-shared attribute for a synchronization object was
not previously tracked, additional new code is needed. for mutexes,
the only place to store the flag is in the type field, so additional
bit masking logic is needed for accessing the type.

for non-process-shared condition variable broadcasts, the futex
requeue operation is unable to requeue from a private futex to a
process-shared one in the mutex structure, so requeue is simply
disabled in this case by waking all waiters.

for robust mutexes, the kernel always performs a non-private wake when
the owner dies. in order not to introduce a behavioral regression in
non-process-shared robust mutexes (when the owning thread dies), they
are simply forced to be treated as process-shared for now, giving
correct behavior at the expense of performance. this can be fixed by
adding explicit code to pthread_exit to do the right thing for
non-shared robust mutexes in userspace rather than relying on the
kernel to do it, and will be fixed in this way later.

since not all supported kernels have private futex support, the new
code detects EINVAL from the futex syscall and falls back to making
the call without the private flag. no attempt to cache the result is
made; caching it and using the cached value efficiently is somewhat
difficult, and not worth the complexity when the benefits would be
seen only on ancient kernels which have numerous other limitations and
bugs anyway.

fix #ifdef inside a macro argument list in __init_tls.c

C99 6.10.3p11 disallows such constructs
so use an #ifdef outside of the argument list of __syscall

fix CPU_EQUAL macro in sched.h

add inline isspace in ctype.h as an optimization

isspace can be a bottleneck in a simple parser, inlining it
gives slightly smaller and faster code

src/locale/pleval.o already had this optimization, the size
change for other libc functions for i386 is

src/internal/intscan.o     2134    2118   -16
src/locale/dcngettext.o    1562    1552   -10
src/network/res_msend.o    1961    1940   -21
src/network/lookup_name.o  2627    2608   -19
src/network/getnameinfo.o  1814    1811    -3
src/network/lookup_serv.o   643     624   -19
src/stdio/vfscanf.o        2675    2663   -12
src/stdlib/atoll.o          117     107   -10
src/stdlib/atoi.o            95      91    -4
src/stdlib/atol.o            95      91    -4
src/time/strptime.o        1515    1503   -12
(TOTALS)                 432451  432321  -130

add dlerror message for static-linked dlsym failure

fix dlerror when using dlopen with a static libc

when the dynamic loader is disabled, dlopen fails correctly but dlerror
did not return a human readable error string like it should have.

make clearenv available with _BSD_SOURCE

glibc declares clearenv under _BSD_SOURCE, some applications might
depend on it being available this way.

make endmntent function handle null argument

The function originates from SunOS 4.x in which the null argument
is allowed. glibc also handles this case.

release 1.1.4

update notice on broken gcc versions in INSTALL file

update COPYRIGHT file to reflect new contributors

harden locale name handling and prevent slashes in LC_MESSAGES

the code which loads locale files was already rejecting locale names
containing slashes. however, LC_MESSAGES records a locale name even if
libc does not have a matching locale file, so that gettext or
application code can use the recorded locale name for message
translations to languages that libc does not support. this recorded
name was not being checked for slashes, meaning that such code could
potentially be tricked into directory traversal.

in addition, since the value of a locale category is sometimes used as
a pathname component by callers, the improved code rejects any value
beginning with a dot. this prevents traversal to the parent directory
via "..", use of the top-level locale directory via ".", and also
avoids "hidden" directories as a side effect.

finally, overly long locale names are now rejected (treated as an
unrecognized name and thus as an alias for C.UTF-8) rather than being
truncated.

implement ffsl and ffsll functions

per the resolution of Austin Group issue #617, these are accepted for
XSI option in POSIX future and thus I'm treating them as standard
functions.

limit visibility of ffs function declaration to _XOPEN_SOURCE

per the standard, ffs is XSI shaded, whereas the other functions in
this header are in the base.

fix broken offset argument to the mmap2 syscall on or1k

for or1k, the kernel expects the offset passed to mmap2 in units of
the 8k page size, not the standard unit of 4k used on most other
archs.

add framework for mmap2 syscall unit to vary by arch

provide PAGE_SIZE as a constant value of 8192 on or1k

according to Stefan Kristiansson, or1k page size is not actually
variable and the value of 8192 is part of the ABI.

plural rule evaluator rewrite for dcngettext

using an operator precedence parser the code size
became smaller and it is only slower by about %10

size of old vs new pleval.o on different archs:
(with inlined isspace added to pleval.c for now)

old:
   text    data     bss     dec     hex filename
    828       0       0     828     33c pl.i386.o
   1152       0       0    1152     480 pl.arm.o
   1704       0       0    1704     6a8 pl.mips.o
   1328       0       0    1328     530 pl.ppc.o
    992       0       0     992     3e0 pl.x64.o
new:
   text    data     bss     dec     hex filename
    693       0       0     693     2b5 pl.i386.o
    972       0       0     972     3cc pl.arm.o
   1276       0       0    1276     4fc pl.mips.o
   1087       0       0    1087     43f pl.ppc.o
    846       0       0     846     34e pl.x64.o

reimplement if_nameindex and getifaddrs using netlink

the previous implementations had several deficiencies, the most severe
of which was the inability to report unconfigured interfaces or
interfaces without ipv4 addresses. among the options discussed for
fixing this, using netlink turned out to be the one with the least
cost and most additional advantages. other improvements include:

if_nameindex now avoids duplicates in the list it produces, but still
includes legacy-style interface aliases if any are in use.

getifaddrs now reports hardware addresses and includes the scope_id
for link-local ipv6 addresses in the resulting address.

fix terminal control ioctl constants for sh

this commit changes the names to match the kernel names, exposing
under the normal names the "old" versions which work with a smaller
termios structure compatible with the userspace structure, and
renaming the "new" versions with "2" on the end like the kernel has.

this fixes spurious warnings "Unsupported ioctl: cmd=0x802c542a" from
qemu-sh4 and should be more correct anyway, since our userspace
termios structure does not have meaningful information in the part
which the kernel would be interpreting as speeds with the new ioctl.

tweaks to plural rules evaluator

const parsing, depth accounting and failure handling was changed
a bit so the generated code is slightly smaller.

harden dcngettext plural processing

while the __mo_lookup backend can verify that the translated message
ends with a null terminator, is has no way to know nplurals and thus
no way to verify that sufficiently many null terminators are present
in the string to satisfy all plural forms. the code in dcngettext was
already attempting to avoid reading past the end of the mo file
mapping, but failed to do so because the strlen call itself could
over-read. using strnlen instead allows us to avoid the problem.

harden mo file processing for locale/translations

rather than just checking that the start of the string lies within the
mapping, also check that the nominal length remains within the
mapping, and that the null terminator is present at the nominal
length. this ensures that the caller, using the result as a C string,
will not read past the end of the mapping.

the nominal length is never exposed to the caller, but it's useful
internally to find where the null terminator should be without having
to restort to linear search via strnlen/memchr.

implement non-default plural rules for ngettext translations

the new code in dcngettext was written by me, and the expression
evaluator by Szabolcs Nagy (nsz).

remove unused a_cas_l from or1k atomic.h

this follows the same logic as in the previous commit for other archs.

clean up unused and inconsistent atomics in arch dirs

the a_cas_l, a_swap_l, a_swap_p, and a_store_l operations were
probably used a long time ago when only i386 and x86_64 were
supported. as other archs were added, support for them was
inconsistent, and they are obviously not in use at present. having
them around potentially confuses readers working on new ports, and the
type-punning hacks and inconsistent use of types in their definitions
is not a style I wish to perpetuate in the source tree, so removing
them seems appropriate.

fix insufficient synchronization in sh atomic asm

while other usage I've seen only has the synco instruction after the
atomic operation, I cannot find any documentation indicating that this
is correct. certainly all stores before the atomic need to have been
synchronized before the atomic operation takes place.

implement gettext message translation functions

this commit replaces the stub implementations with working message
translation functions. translation units are factored so as to prevent
pulling in the legacy, non-library-safe functions which use a global
textdomain in modern code which is using the versions with an explicit
domain argument. bind_textdomain_codeset is also placed in its own
file since it should not be needed by most programs.

this implementation is still missing some features: the LANGUAGE
environment variable (for multiple fallback languages) is not honored,
and non-default plural-form rules are not supported. these issues will
be addressed in a later commit.

one notable difference from the GNU implementation is that there is no
default path for loading translation files. in principle one could be
added, but since the documented correct usage is to call the
bindtextdomain function, a default path is probably unnecessary.

add support for LC_TIME and LC_MESSAGES translations

for LC_MESSAGES, translation of strerror and similar literal message
functions is supported. for messages in other places (particularly the
dynamic linker) that use format strings, translation is not yet
supported. in order to make it possible and safe, such messages will
need to be refactored to separate the textual content from the format.

for LC_TIME, the day and month names and strftime-style format strings
provided by nl_langinfo are supported for translation. however there
may be limitations, as some of the original C-locale nl_langinfo
strings are non-unique and thus perhaps non-suitable as keys.

overall, the locale support activated by this commit should not be
seen as complete and polished but as a basis for beginning to test
locale functionality and implement locales.

add missing yes/no strings to nl_langinfo

these were removed from the standard but still offered as an extension
in langinfo.h, so nl_langinfo should support them.

fix nl_langinfo table for LC_TIME era-related items

due to a skipped slot and missing null terminator, the last few
strings were off by one or two slots from their item codes.

implement mo file string lookup for translations

the core is based on a binary search; hash table is not used. both
native and reverse-endian mo files are supported. all offsets read
from the mapped mo file are checked against the mapping size to
prevent the possibility of reads outside the mapping.

this commit has no observable effects since there are not yet any
callers to the message translation code.

implement locale file loading and state for remaining locale categories

there is still no code which actually uses the loaded locale files, so
the main observable effect of this commit is that calls to setlocale
store and give back the names of the selected locales for the
remaining categories (LC_TIME, LC_COLLATE, LC_MONETARY) if a locale
file by the requested name could be loaded.

fix locale environment variable logic for empty strings

per POSIX (XBD 8.2) LC_*/LANG environment variables set to to the
empty string are supposed to be treated as if they were not set at
all.

add new PR_SET_THP_DISABLE and PR_GET_THP_DISABLE prctl flags

they can be used to set or query if transparent huge pages are disabled.
introduced in linux 3.15 commit a0715cc22601e8830ace98366c0c2bd8da52af52

add pacing rate information to the tcp_info struct in tcp.h

used by monitoring applications such as ss from iproute2
introduced in linux 3.15 commit 977cb0ecf82eb6d15562573c31edebf90db35163

add new ethernet packet types ETH_P_80221, ETH_P_LOOPBACK

ETH_P_80221 is ethertype for IEEE Std 802.21 - Media Independent Handover Protocol
introduced in linux 3.15 commit b62faf3cdc875a1ac5a10696cf6ea0b12bab1596

ETH_P_LOOPBACK is the correct packet type for loopback in IEEE 802.3*
introduced in linux 3.15 commit 61ccbb684421d374fdcd7cf5d6b024b06f03ce4e

some defines were shuffled to be in ascending order and match the kernel header

add syscall numbers for the new renameat2 syscall

it's like rename but with flags eg. to allow atomic exchange of two files,
introduced in linux 3.15 commit 520c8b16505236fc82daa352e6c5e73cd9870cff

fix regression that negated some mips syscall error returns

due to what was essentially a copy and paste error, the changes made
in commit f61be1f875a2758509d6e9e2cf6f1d9603b28b65 caused syscalls
with 5 or 6 arguments (and syscalls with 2, 3, or 4 arguments when
compiled with clang compatibility) to negate the returned error code a
second time, breaking errno reporting.

fix mips struct stat dev_t members for big endian

the mips version of this structure on the kernel side wrongly has
32-bit type rather than 64-bit type. fortunately there is adjacent
padding to bring it up to 64 bits, and on little-endian, this allows
us to treat the adjacent kernel st_dev and st_pad0[0] as as single
64-bit dev_t. however, on big endian, such treatment results in the
upper and lower 32-bit parts of the dev_t value being swapped. for the
purpose of just comparing st_dev values this did not break anything,
but it precluded actually processing the device numbers as major/minor
values.

since the broken kernel behavior that needs to be worked around is
isolated to one arch, I put the workarounds in syscall_arch.h rather
than adding a stat fixup path in the common code. on little endian
mips, the added code optimizes out completely.

the changes necessary were incompatible with the way the __asm_syscall
macro was factored so I just removed it and flattened the individual
__syscallN functions. this arguably makes the code easier to read and
understand, anyway.

add issetugid function to check for elevated privilege

this function provides a way for third-party library code to use the
same logic that's used internally in libc for suppressing untrusted
input/state (e.g. the environment) when the application is running
with privleges elevated by the setuid or setgid bit or some other
mechanism. its semantics are intended to match the openbsd function by
the same name.

there was some question as to whether this function is necessary:
getauxval(AT_SECURE) was proposed as an alternative. however, this has
several drawbacks. the most obvious is that it asks programmers to be
aware of an implementation detail of ELF-based systems (the aux
vector) rather than simply the semantic predicate to be checked. and
trying to write a safe, reliable version of issetugid in terms of
getauxval is difficult. for example, early versions of the glibc
getauxval did not report ENOENT, which could lead to false negatives
if AT_SECURE was not present in the aux vector (this could probably
only happen when running on non-linux kernels under linux emulation,
since glibc does not support linux versions old enough to lack
AT_SECURE). as for musl, getauxval has always properly reported
errors, but prior to commit 7bece9c2095ee81f14b1088f6b0ba2f37fecb283,
the musl implementation did not emulate AT_SECURE if missing, which
would result in a false positive. since musl actually does partially
support kernels that lack AT_SECURE, this was problematic.

the intent is that library authors will use issetugid if its
availability is detected at build time, and only fall back to the
unreliable alternatives on systems that lack it.

patch by Brent Cook. commit message/rationale by Rich Felker.

fix or1k atomic store

at the very least, a compiler barrier is required no matter what, and
that was missing. current or1k implementations have strong ordering,
but this is not guaranteed as part of the ISA, so some sort of
synchronizing operation is necessary.

in principle we should use l.msync, but due to misinterpretation of
the spec, it was wrongly treated as an optional instruction and is not
supported by some implementations. if future kernels trap it and treat
it as a nop (rather than illegal instruction) when the
hardware/emulator does not support it, we could consider using it.

in the absence of l.msync support, the l.lwa/l.swa instructions, which
are specified to have a built-in l.msync, need to be used. the easiest
way to use them to implement atomic store is to perform an atomic swap
and throw away the result. using compare-and-swap would be lighter,
and would probably be sufficient for all actual usage cases, but
checking this is difficult and error-prone:

with store implemented in terms of swap, it's guaranteed that, when
another atomic operation is performed at the same time as the store,
either the result of the store followed by the other operation, or
just the store (clobbering the other operation's result) is seen. if
store were implemented in terms of cas, there are cases where this
invariant would fail to hold, and we would need detailed rules for the
situations in which the store operation is well-defined.

fix missing barriers in powerpc atomic store

fix microblaze atomic store

as far as I can tell, microblaze is strongly ordered, but this does
not seem to be well-documented and the assumption may need revisiting.
even with strong ordering, however, a volatile C assignment is not
sufficient to implement atomic store, since it does not preclude
reordering by the compiler with respect to non-volatile stores and
loads.

simply flanking a C store with empty volatile asm blocks with memory
clobbers would achieve the desired result, but is likely to result in
worse code generation, since the address and value for the store may
need to be spilled. actually writing the store in asm, so that there's
only one asm block, should give optimal code generation while
satisfying the requirement for having a compiler barrier.

fix missing barrier instructions in powerpc atomic asm

fix missing barrier instructions in mips atomic asm

previously I had wrongly assumed the ll/sc instructions also provided
memory synchronization; apparently they do not. this commit adds sync
instructions before and after each atomic operation and changes the
atomic store to simply use sync before and after a plain store, rather
than a useless compare-and-swap.

use memory constraints for mips atomic asm

despite lacking the semantic content that the asm accesses the
pointed-to object rather than just using its address as a value, the
mips asm was not actually broken. the asm blocks were declared
volatile, meaning that the compiler must treat them as having unknown
side effects.

however changing the asm to use memory constraints is desirable not
just from a semantic correctness and consistency standpoint, but also
produces better code. the compiler is able to use base/offset
addressing expressions for the atomic object's address rather than
having to load the address into a single register. this improves
access to global locks in static libc, and access to non-zero-offset
atomic fields in synchronization primitives, etc.