these functions are specified to write to stderr but not set its
orientation, presumably so that they can be used in programs operating
stderr in wide mode. also, they are not allowed to clobber errno on
success. save and restore to meet the requirement.

psiginfo is reduced to a think wrapper around psignal, since it
already behaved the same. if we want to add more detailed siginfo
printing at some point this will need refactoring.

if no output is produced, no underlying fwrite will ever be called,
but byte-oriented printf functions are still required to set the
orientation of the stream to byte-oriented. call __towrite explicitly
if the FILE is not already in write mode.

commit b5a8b289 setup the write buffer
bound pointers for the temporary buffer manually to fix a buffer
overflow issue, but in doing so, caused vfprintf on unbuffered files
never to call __towrite, thereby failing to set the stream orientation
to byte-oriented, failing to clear any prior read mode, and failing to
produce an error when the stream is not writable.

revert the inline setup of the bounds pointers and instead zero them,
so that the underlying fwrite code will call __towrite to set them up.

commit 0b80a7b0 added the ability to
set application-provided stdio FILE buffers, adding the possibility
that stderr might be buffered at exit time, but __stdio_exit did not
have code to flush it.

this regression was not present in any release.

if __cp_cancel was reached via __syscall_cp, r12 will necessarily
still contain a GOT pointer (for libc.so or for the static-linked main
program) valid for entering __cancel. however, in the case of async
cancellation, r12 may contain any scratch value; it's not necessarily
even a valid GOT pointer for the code that was interrupted.

unlike in commit 0ec49dab where the
corresponding issue was fixed for powerpc64, there is fundamentally no
way for fdpic code to recompute its GOT pointer. so a new mechanism is
introduced for cancel_handler to write a GOT register value into the
interrupted context on archs where it is needed.

entering the local entry point for __cancel from __cp_cancel is valid
if __cp_cancel was reached from __syscall_cp, since both are in libc
and share the same TOC pointer, but it is not valid if __cp_cancel was
reached when cancel_handler rewrote the program counter for
asynchronous cancellation of code outside libc.

to ensure __cancel is entered with a valid TOC pointer, recompute the
correct value in a PC-relative manner before jumping.

- REALTIME_SIGNALS is supposed to be version-valued
- DELAYTIMER_MAX was wrongly using the min allowed max
- unavailable compilation environments wrongly used 0 instead of -1

the value 0x7f00 (as if by _exit(127)) is specified only for the case
where the child is created but then fails to exec the shell, since
traditional fork+exec implementations do not admit reporting an error
via errno in this case without additional machinery. it's unclear
whether an implementation not subject to this failure mode needs to
emulate it; one could read the standard as requiring that. if so,
additional code will need to be added to map posix_spawn errors into
the form system is expected to return. but for now, returning -1 to
indicate an error is significantly better behavior than always
reporting failures as if the shell failed to exec after fork.

fundamentally there is no good reason these functions need to set an
orientation (morally it should be possible to write a wchar_t[] memory
stream using byte functions, or a char[] memory stream using wide
functions), but it's a part of the specification that they do. aside
from being able to inspect the orientation with fwide, failure to set
the orientation in open_wmemstream is observable if the locale changes
between open_wmemstream and the first operation on the stream; this is
because the encoding rule (locale) for the stream is required to be
bound at the time the stream becomes wide-oriented.

for open_wmemstream, call fwide to avoid duplicating the logic for
binding the encoding rule. for open_memstream it suffices just to set
the mode field in the FILE struct.

the w+ mode is specified to "truncate the buffer contents". like most
of fmemopen, exactly what this means is underspecified. mode w and w+
of course implicitly 'truncate' the buffer if a write from the initial
position is flushed, so in order for this part of the text about w+
not to be spurious, it should be interpreted as requiring something
else, and the obvious reasonable interpretation is that the truncation
is immediately visible if you attempt to read from the stream or the
buffer before writing/flushing.

this interpretation agrees with reported conformance test failures.

this is a POSIX requirement.

also remove the gratuitous locking shenanigans and simply access f->fd
under control of the lock. there is no advantage to not doing so, and
it made the correctness non-obvious at best.

this is a POSIX requirement.

__aeabi_read_tp used to call c code, but that was incorrect as the
arm runtime abi specifies special pcs for this function: it is only
allowed to clobber r0, ip, lr and cpsr.

maintainer's note: the old code explicitly saved and restored all
general-purpose registers which are call-clobbered in the normal
calling convention, so it's unlikely that any real-world compilers
produced code that could break. however theoretically they could have
chosen to use floating point registers, in which case the caller's
values of those registers would be clobbered.

commit 201995f3 introduced a hack
utilizing the signedness of character constants at the preprocessor
level to avoid depending on the gcc-specific __CHAR_UNSIGNED__ predef.
while this trick works on gcc and presumably other compilers being
used, it's not clear that the behavior it depends on is actually
conforming. C11 6.4.4.4 ¶10 defines character constants as having type
int, and 6.10.1 ¶4 defines preprocessor #if arithmetic to take place
in intmax_t or uintmax_t, depending on the signedness of the integer
operand types, and it is specified that "this includes interpreting
character constants".

if character literals had type char and just promoted to int, it would
be clear that when char is unsigned they should behave as uintmax_t at
the preprocessor level. however, as written the text of the standard
seems to require that character constants always behave as intmax_t,
corresponding to int, at the preprocessor level.

since there is a good deal of ambiguity about the correct behavior and
a risk that compilers will disagree or that an interpretation may
mandate a change in the behavior, do not rely on it for defining
CHAR_MIN and CHAR_MAX correctly. instead, use the signedness of the
value (as opposed to the type) of '\xff', which will be positive if
and only if plain char is unsigned. this behavior is clearly
specified, and the specific case '\xff' is even used in an example,
under 6.4.4.4 of the standard.

with async cancellation enabled, pthread_cancel(pthread_self())
deadlocked due to pthread_kill holding killlock which is needed by
pthread_exit.

this could be solved by making pthread_kill block signals around the
critical section, at least when the target thread is itself, but the
issue only arises for cancellation, and otherwise would just be
imposing unnecessary cost.

instead just have pthread_cancel explicitly check for async
self-cancellation and call pthread_exit(PTHREAD_CANCELED) directly
rather than going through the signal machinery.

This manifests itself in mktime if tm_isdst = 1 and the current TZ= is
a POSIX timezone specification. mktime would see that tm_isdst was set
to 0 by __secs_to_zone, and subtract 'oppoff' (dst_off) - gmtoff from
the resultant time. This meant that mktime returned a time that was
exactly double the GMT offset of the desired timezone when tm_isdst
was = 1.

commit 610c5a85 changed the thread
pointer setup so tp points at the end of the pthread struct on arm,
but failed to update __aeabi_read_tp so it was off by 8.

this broke tls access in code that is compiled with -mtp=soft, which
is the default when target arch is pre armv6k or thumb1.

maintainer's note: no release versions are affected.

this is an obsolete error code from RFS, an obsolete predecessor of
NFS. POSIX documents it only as "Reserved", but maintains the
requirement that it be defined. as long as it is defined, it needs a
string for strerror to produce; the one chosen matches glibc and
documentation from other language runtimes I could find.

the code to perform rounding to the desired precision wrongly assumed
the long double mantissa was an integral number of nibbles (hex
digits) in length. this is true for 80-bit extended precision (64-bit
mantissa) but not for double (53) or quad (113).

scale the rounding value by 1<<(LDBL_MANT_DIG%4) to compensate.

the text of the specification for getopt's handling of options that
require an argument, which requires updating optarg and optind, does
not exclude the error case where the end of the argument list has been
reached. in that case, it is expected that optarg be assigned
argv[argc] (normally null) and optind be incremented by 2, resulting
in a value of argc+1.

commit 98c9af50 wrongly claimed they
do not need to be valid for such usage, but the last sentence of C11
7.1.4 ¶1 imposes a broad requirement that all macros specified as
integer constant expressions also need to be valid for #if.

simply write the value out explicitly. there is no value here in
pretending that the width of int will vary.

POSIX requires the symlink function to fail with ENAMETOOLONG if the
link contents to be written exceed SYMLINK_MAX in length, but neither
Linux nor our syscall wrapper code enforce this. the value 255 for
SYMLINK_MAX is not meaningful and does not seem to have been motivated
by anything except perhaps a wrong assumption that a definition was
mandatory. it has been present (though moving through bits to
top-level limits.h) since the beginning of the project history.

[f]pathconf is entitled to return -1 as the limit for conf names for
which there is no hard limit, with the usual POSIX note that an
indefinite limit does not imply an infinite limit. in principle we
might should report a limit for filesystems that impose one, but such
functionality is not currently present for any of the pathconf limits,
and adding it is beyond the scope of fixing the incorrect limit.

Call SYS_exit on return from fn in __clone. This is the expected
behavior of this function. Without this the child task will crash on
return from fn, since it will return to nowhere.

due to moved code, commit b8742f32
inadvertently used the return value of __clone, rather than the return
value of SYS_sched_setscheduler in the new thread, to check whether it
needed to report failure. since a successful __clone returns the tid
of the new thread, which is never zero, this caused pthread_create
always to return with an invalid error number in the code path for
PTHREAD_EXPLICIT_SCHED.

this regression was not present in any releases.

the sign character produced came from the sign of tm_gmtoff/3600 as an
integer division, which is zero for negative offsets smaller in
magnitude than 3600. instead of printing the hours and minutes as
separate fields, print them as a single value of the form
hours*100+minutes, which naturally has the correct sign.

the specfile for the wrapper was written assuming output is pie only
if -pie appears on the command line. recent (and older patched)
versions of gcc can be configured to produce pie output by default,
adn when used with such a toolchain, the wrapper linked the wrong
startfiles (crt*) containing pic-incompatible code.

rather than trying to figure out gcc's default, simply always use the
pic-compatible start files.

this fixes a major gap in the intended functionality of
pthread_setattr_default_np. if application/library code creating a
thread does not pass a null attribute pointer to pthread_create, but
sets up an attribute object to change other properties while leaving
the stack alone, the created thread will get a stack with size
DEFAULT_STACK_SIZE. this makes pthread_setattr_default_np useless for
working around stack overflow issues in such applications, and leaves
a major risk of regression if previously-working code switches from
using a null attribute pointer to an attribute object.

this change aligns the behavior more closely with the glibc
pthread_setattr_default_np functionality too, albeit via a different
mechanism. glibc encodes "default" specially in the attribute object
and reads the actual default at thread creation time. with this
commit, we now copy the current default into the attribute object at
pthread_attr_init time, so that applications that query the properties
of the attribute object will see the right values.

maintainer's note: the key observation here is that the compared
element is the first slot of the second ceil(half) of the array, and
thus can be removed for further comparison when it does not match, so
that we descend into the second ceil(half)-1 rather than ceil(half)
elements. this change ensures that nel strictly decreases with each
iteration, so that the case of != but nel==1 does not need to be
special-cased anymore.

maintainer's note: while musl does not use the linux kernel headers,
it does provide these three sys/* headers which do nothing but include
the corresponding linux/* headers, since the sys/* versions are the
ones documented for application use (and they arguably provide
interfaces that are not linux-specific but common to other unices).
these headers should probably not be provided by libc (rather by a
separate package), but as long as they are, use the bits header
framework as an aid to out-of-tree ports of musl for non-linux systems
that want to implement them in some other way.

maintainer's note: at some point, probably long before linux separated
the uapi headers, it was the case, or at least I believed it was the
case, that linux/types.h was unsafe to include from userspace. thus,
the inclusion guard macro _LINUX_TYPES_H was defined in sys/kd.h to
prevent linux/kd.h from including linux/types.h (which it spuriously
includes but does not use). as far as I can tell, whatever problem
this was meant to solve does not seem to have been present for a long
time, and the hack was not done correctly anyway, so removing it is
the right thing to do.

commit 32482f61 reduced the number of
int members before the dirent buf from 4 to 3, thereby misaligning it
mod sizeof(off_t), producing invalid accesses on any arch where
alignof(off_t)==sizeof(off_t).

rather than re-adding wasted padding, reorder the struct to meet the
requirement and add a comment and static assertion to prevent this
from getting broken again.

sys/ptrace.h is target specific, use bits/ptrace.h to add target
specific macro definitions.

these macros are kept in the generic sys/ptrace.h even though some
targets don't support them:

PTRACE_GETREGS
PTRACE_SETREGS
PTRACE_GETFPREGS
PTRACE_SETFPREGS
PTRACE_GETFPXREGS
PTRACE_SETFPXREGS

so no macro definition got removed in this patch on any target. only
s390x has a numerically conflicting macro definition (PTRACE_SINGLEBLOCK).

the PT_ aliases follow glibc headers, otherwise the definitions come
from linux uapi headers except ones that are skipped in glibc and
there is no real kernel support (s390x PTRACE_*_AREA) or need special
type definitions (mips PTRACE_*_WATCH_*) or only relevant for linux
2.4 compatibility (PTRACE_OLDSETOPTIONS).

new in linux v3.1 commit 3544d72a0e10d0aa1c1bd59ed77a53a59cdc12f7
changed in linux v3.4 commit 5cdf389aee90109e2e3d88085dea4dd5508a3be7

A tracer recieves this event in the waitpid status of a PTRACED_SEIZED
process.

including uchar.h in c++ code is only well defined in c++11 onwards
where char16_t and char32_t type definitions must be hidden since they
are keywords.  however some c++ code compiled for older c++ standard
include uchar.h too and they need the typedefs, this fix makes such
code work.

previously, this operation succeeded, and the relocation results
worked for access from new threads created after dlopen, but produced
invalid accesses (and possibly clobbered other memory) from threads
that already existed.

the way the check is written, it still permits dlopen of libraries
containing initial-exec references to static TLS (TLS in the main
program or in a dynamic library loaded at startup).

tls_id is one-based, whereas [static_]tls_cnt is a count, so
comparison for checking that a given tls_id is dynamic rather than
static needs to use strict inequality.

this flag is notoriously under-/mis-specified, and in the past it was
implemented as a nop, essentially considering the absence of a
loopback interface with 127.0.0.1 and ::1 addresses an unsupported
configuration. however, common real-world container environments omit
IPv6 support (even for the network-namespaced loopback interface), and
some kernels omit IPv6 support entirely. future systems on the other
hand might omit IPv4 entirely.

treat these as supported configurations and suppress results of the
unconfigured/unsupported address families when AI_ADDRCONFIG is
requested. use routability of the loopback address to make the
determination; unlike other implementations, we do not exclude
loopback from the "an address is configured" condition, since there is
no basis in the specification for such exclusion. obtaining a result
with AI_ADDRCONFIG does not imply routability of the result, and
applications must still be able to cope with unroutable results even
if they pass AI_ADDRCONFIG.

commit 0b80a7b0, which added non-stub
setvbuf, applied the UNGET pushback adjustment to the size of the
buffer passed in, but inadvertently omitted offsetting the start by
the same amount, thereby allowing unget to clobber up to 8 bytes
before the start of the buffer. this bug was introduced in the present
release cycle; no releases are affected.