currently five targets use the same mman.h constants and the rest
share most constants too, so move them to sys/mman.h before the
bits/mman.h include where the differences can be corrected by
redefinition of the macros.

this fixes two minor bugs: POSIX_MADV_DONTNEED was wrong on most
targets (it should be the same as MADV_DONTNEED), and sh defined
the x86-only MAP_32BIT mmap flag.

the idiom fprintf(f, "%.*s", n, "") was wrongly used in vfwprintf as a
means of producing n spaces; instead it produces no output. the
correct form is fprintf(f, "%*s", n, ""), using width instead of
precision, since for %s the later is a maximum rather than a minimum.

these changes should not affect generated code, but they reflect that
the underlying objects operated on by a_cas_p are supposed to have
type volatile void *, not volatile long. in theory a compiler could
treat the effective type mismatch in the "m" memory operands as
undefined behavior.

apparently clang does not accept matching-register input and output
constraints that differ in size (32-bit vs 64-bit).

based on patch by Jaydeep Patil.

the SPE ABI may be compatible with soft-float, but actually making it
work requires some additional work, so for now it's best to make sure
broken builds don't happen.

Some PowerPC CPUs (e.g. Freescale MPC85xx) have a completely different
instruction set for floating point operations (SPE).
Executing regular PowerPC floating point instructions results in
"Illegal instruction" errors.

Make it possible to run these devices in soft-float mode.

This is the minimal fix for __putenv leaving a pointer to freed heap
storage in __env_map array, which could later on lead to errors such
as double-free.

patch by Mahesh Bodapati and Jaydeep Patil of Imagination
Technologies.

this change is made in preparation for adding the mips64 port, which
needs a 64-bit (and mips64-specific) form of the R_INFO macro, but
it's a better abstraction anyway.

based on part of the mips64 port patch by Mahesh Bodapati and Jaydeep
Patil of Imagination Technologies.

expf(-NAN) was treated as expf(-large) which unconditionally
returns +0, so special case +-NAN.
reported by Petr Hosek.

This brings the call to an actually usable speed.
Quick unscientific benchmark: 14ns : 102ns :: vDSO : syscall

This is a GNU extension, but a fairly minor one, for a system call that
otherwise has no libc wrapper.

This is a workaround to treat * as literal * at the start of a BRE.

Ideally ^ would be treated as an anchor at the start of any BRE
subexpression and similarly $ would be an anchor at the end of any
subexpression.  This is not required by the standard and hard to do
with the current code, but it's the existing practice.  If it is
changed, * should be treated as literal after such anchor as well.

commit 7eaa76fc made * invalid at
the start of a BRE subexpression, but it should be accepted as
literal * there according to the standard.

This patch does not fix subexpressions starting with ^*.

name_from_hosts failed to account for the possibility of an address
family error from name_from_numeric, wrongly counting such a return as
success and using the uninitialized address data as part of the
results passed up to the caller.

non-matching address family entries cannot simply be ignored or
results would be inconsistent with respect to whether AF_UNSPEC or a
specific address family is queried. instead, record that a
non-matching entry was seen, and fail the lookup with EAI_NONAME of no
matching-family entries are found.

at present this is done only for consistency, since this file defines
its own a_cas_p rather than using the new generic one from atomic.h
added in commit 225f6a6b. these
definitions may however be useful if we ever need to add other
pointer-sized atomic operations.

No current ports do this, but it will be useful for porting to 64-bit ll/sc
architectures, such as mips64 and powerpc64.

this follows the principle of having the source tree layout define
build semantics. it also makes it possible for crt/$(ARCH) to define
additional installable files, which may be needed for midipix and
other future targets.

the nt32 and nt64 archs will be provided by the midipix project for
building musl on top of its posix-like syscall layer for windows. at
present the needed arch files are in a separate repository, but having
the tuple matching in the upstream configure script should make it
possible to overlay the arch files without needing any further
patching.

commit e4355bd6 moved the math asm
from external source files to inline asm, but unfortunately, all
current releases of clang use the wrong inline asm constraint codes
for float and double ("w" and "P" instead of "t" and "w",
respectively). this patch adds detection for the bug in configure,
and, for now, just disables the affected asm on broken clang versions.

in order to take advantage of the fpu in -mfloat-abi=softfp mode, the
__VFP_FP__ (presence of vfp fpu) was checked instead of checking for
__ARM_PCS_VFP (hardfloat EABI variant). however, the latter macro is
the one that's actually specified by the ABI documents rather than
being compiler-specific, and should also be checked in case __VFP_FP__
is not defined on some compilers or some configurations.

these additions were made based on scanning commit authors since the
last update, at the time of the 1.1.7 release, and adding everyone
with either substantial code contributions or a pattern of ongoing
simple patch submission.

the dynamic linker was found to hang when used as the PT_INTERP, but
not when invoked as a command. the mechanism of this failure was not
determined, but the cause is clear:

commit 5552ce52 removed the SHARED
macro, but arch/sh/crt_arch.h is still using it to choose the right
form of the crt/ldso entry point code. moving the forced definition
from rcrt1.c to dlstart.c restores the old behavior. eventually the
logic should be changed to fully remove the SHARED macro or at least
rename it to something more reasonable.

commit 80fbaac4 broke all soft-float
archs, where gcc defines __GCC_IEC_559==0 because rounding modes and
exception flags are not supported. for now, just check for
__FAST_MATH__ as an indication of broken float. this won't detect all
possible misconfigurations but it probably catches the most common
one.

commit 2f853dd6 moved the error
handling for $(ARCH) not being set such that it applied to all
targets, including clean and distclean. previously these targets
worked even in an unconfigured tree. to restore the old behavior, make
most of the makefile body conditional on $(ARCH) being set/non-empty
and produce the error via a fake "all" target in the conditional
branch for the case where $(ARCH) is empty.

prior to commit 2f853dd6 which
overhauled the makefile for out-of-tree builds, crt/*.c files were
replaceable by crt/$(ARCH)/*.s, and top-level ldso/ did not exist (its
files were under src/ldso). since then, crti.o and crtn.o have been
hard-coded as arch-specific, but none of the other files in crt/ or
ldso/ were replaceable at all.

in preparation for easy integration with midipix, which has a port of
musl to windows, it needs to be possible to override the ELF-specific
code in these files. making the same arch-replacements system work
throughout the whole source tree also improves consistency and removes
the need for some file-specific rules (crti.o and crtn.o) in the
makefile.

the reference implementation clamps rounds to [1000,999999999]. we
further limited rounds to at most 9999999 as a defense against extreme
run times, but wrongly clamped instead of treating out-of-bounds
values as an error, thereby producing implementation-specific hash
results. fixing this should not break anything since values of rounds
this high are not useful anyway.

like fputs (see commit 10a17dfb), the
message printing code for getopt assumed that fwrite only returns 0 on
failure, but it can also happen on success if the total length to be
written is zero. programs with zero-length argv[0] were affected.

commit 500c6886 introduced this
problem in getopt by fixing the fwrite behavior to conform to the
requirements of ISO C. previously the wrong expectations of the getopt
code were met by the fwrite implementation.

internally, the idiom of passing nmemb=1 to fwrite and interpreting
the return value of fwrite (which is necessarily 0 or 1) as
failure/success is fairly widely used. this is not correct, however,
when the size argument is unknown and may be zero, since C requires
fwrite to return 0 in that special case. previously fwrite always
returned nmemb on success, but this was changed for conformance with
ISO C by commit 500c6886.

some software simply uses static_assert if the macro is defined, and
this breaks if the compiler does not recognize the _Static_assert
keyword used to define it.

commit 378f8cb5 added these functions
(as stubs) but left them without declarations. this broke some
autoconf based software that detected linkability of the symbols but
didn't check for a declaration.

when the size argument was zero but nmemb was nonzero, these functions
were returning nmemb, despite no data having been written.
conceptually this is not wrong, but the standard requires a return
value of zero in this case.

as specified, the int argument providing the character to write is
converted to type unsigned char. for the actual write to buffer,
conversion happened implicitly via the assignment operator; however,
the logic to check whether the argument was a newline used the
original int value. thus usage such as putchar('\n'+0x100) failed to
produce a flush.

when a write error occurred while flushing output due to a newline,
fwrite falsely reported all bytes up to and including the newline as
successfully written. in general, due to buffering such "spurious
success" returns are acceptable for stdio; however for line-buffered
mode it was subtly wrong. errors were still visible via ferror() or as
a short-write return if there was more data past the newline that
should have been written, but since the contract for line-buffered
mode is that everything up through the newline be written out
immediately, a discrepency was observable in the actual file contents.