alpha and s390x gratuitously use 64-bit entries (wasting 2x space and
cache utilization) despite the values always being 32-bit.

based on patch by Bobby Bingham, with changes suggested by Alexander
Monakov to use the public Elf_Symndx type from link.h (and make it
properly variable by arch) rather than adding new internal
infrastructure for handling the type.

commit 31fb174d used
DEFAULT_GUARD_SIZE from pthread_impl.h in a static initializer,
breaking build on archs where its definition, PAGE_SIZE, is not a
constant. instead, just define DEFAULT_GUARD_SIZE as 4096, the minimal
page size on any arch we support. pthread_create rounds up to whole
pages anyway, so defining it to 1 would also work, but a moderately
meaningful value is nicer to programs that use
pthread_attr_getguardsize on default-initialized attribute objects.

based on patch by Timo Teräs:

While generally this is a bad API, it is the only existing API to
affect c++ (std::thread) and c11 (thrd_create) thread stack size.
This patch allows applications only to increate stack and guard
page sizes.

commit 33ce9208 broke pthread_create
in the case where a null attribute pointer is passed; rather than
using the default sizes, sizes of 0 (plus the remainder of one page
after TLS/TCB use) were used.

the linux kernel uapi headers provide their own definitions of the
structures from netinet/in.h, resulting in errors when a program
includes both the standard libc header and one or more of the
networking-related kernel headers that pull in the kernel definitions.

as before, we do not attempt to support the case where kernel headers
are included before the libc ones, since the kernel definitions may
have subtly incorrect types, namespace violations, etc. however, we
can easily support the inclusion of the kernel headers after the libc
ones, since the kernel headers provide a public interface for
suppressing their definitions. this patch adds the necessary macro
definitions for such suppression.

previously, the pthread_attr_t object was always initialized all-zero,
and stack/guard size were represented as differences versus their
defaults. this required lots of confusing offset arithmetic everywhere
they were used. instead, have pthread_attr_init fill in the default
values, and work with absolute sizes everywhere.

the swprintf write callback never reset its buffer pointers, so after
its 256-byte buffer filled up, it would keep repeating those bytes
over and over in the output until the destination buffer filled up. it
also failed to set the error indicator for the stream on EILSEQ,
potentially allowing output to continue after the error.

the overflow check for years+100 did not account for the extra
year computed from the remaining months. instead, perform this
check after obtaining the final number of years.

If a DT_NEEDED entry was the prefix of a reserved library name
(up to the first dot) then it was incorrectly treated as a libc
reserved name.

e.g. libp.so dependency was not loaded as it matched libpthread
reserved name.

this was harmless as load_library is not called concurrently,
but it used one word of bss.

the value 19991006 for __RES implies availability of res_ninit and
related functions that take a resolver state argument; these are not
supported since our resolver is stateless. instead claim support for
just the older API by defining __RES to 19960801.

based on patch by Dmitrij D. Czarkoff.

Fix parsing of the < > quoted time zone names. Compare the correct
character instead of repeatedly comparing the first character.

this header is XSI-shaded itself and thus does not need to limit
specific content to _XOPEN_SOURCE.

the old snprintf design setup the FILE buffer pointers to point
directly into the destination buffer; if n was actually larger than
the buffer size, the pointer arithmetic to compute the buffer end
pointer was undefined. this affected sprintf, which is implemented in
terms of snprintf, as well as some unusual but valid direct uses of
snprintf.

instead, setup the FILE as unbuffered and have its write function
memcpy to the destination. the printf core sets up its own temporary
buffer for unbuffered streams.

reported and changes suggested by Daniel Sabogal.

inclusion of these names was unintentional and in most cases is a
namespace violation. Daniel Sabogal tracked down and reported these.

ETH_P_HSR (IEC 62439-3 HSRv1) added in
linux 4.7 commit ee1c27977284907d40f7f72c2d078d709f15811f

ETH_P_TSN (IEEE 1722) added in
linux 4.3 commit 1ab1e895492d8084dfc1c854efacde219e56b8c1
this constant breaks the ascending order to match the kernel header

ETH_P_XDSA (Multiplexed DSA protocol) added in
linux 3.18 commit 3e8a72d1dae374cf6fc1dba97cec663585845ff9

ARPHRD_6LOWPAN (IPv6 over LoWPAN) added in
linux 3.14 commit 0abc652c796dab74d34d60473ec5594cd21620be

the _CS_V6_ENV and _CS_V7_ENV constants are required to be available for use
with confstr. glibc defines these constants with values 1148 and 1149,
respectively.

the only missing (and required) confstr constants are
_CS_POSIX_V7_THREADS_CFLAGS and _CS_POSIX_V7_THREADS_LDFLAGS which remain
unavailable in glibc.

commit 6ffdc457 set lnz in the code
path for non-zero digits after a huge string of zeros, but the
assignment of dc to lnz truncates if the value of dc does not fit in
int; this is possible for some pathologically long inputs, either via
strings on 64-bit systems or via scanf-family functions.

instead, simply set lnz to match the point at which we add the
artificial trailing 1 bit to simulate nonzero digits after a huge
run of zeros.

the mid-sized integer optimization relies on lnz set up properly
to mark the last non-zero decimal digit, but this was not done
if the non-zero digit lied outside the KMAX digits of the base
10^9 number representation.

so if the fractional part was a very long list of zeros (>2048*9 on
x86) followed by non-zero digits then the integer optimization could
kick in discarding the tiny non-zero fraction which can mean wrong
result on non-nearest rounding mode.

strtof, strtod and strtold were all affected.

in certain cases excessive trailing zeros could cause incorrect
rounding from long double to double or float in decfloat.

e.g. in strtof("9444733528689243848704.000000", 0) the argument
is 0x1.000001p+73, exactly halfway between two representible floats,
this incorrectly got rounded to 0x1.000002p+73 instead of 0x1p+73,
but with less trailing 0 the rounding was fine.

the fix makes sure that the z index always points one past the last
non-zero digit in the base 10^9 representation, this way trailing
zeros don't affect the rounding logic.

accessing an object of type const char *restrict as if it had type
char * is not defined.

in nearest rounding mode exact halfway cases were not following the
round to even rule if the rounding happened at a base 1000000000 digit
boundary of the internal representation and the previous digit was odd.

e.g. printf("%.0f", 1.5) printed 1 instead of 2.

the thread name is displayed by gdb's "info threads".

posix requires that EINVAL be returned if the first parameter specifies
the cpu-time clock of the calling thread (CLOCK_THREAD_CPUTIME_ID).
linux returns ENOTSUP instead so we handle this.

j is int32_t and thus j<<31 is undefined if j==1, so j is changed to
uint32_t locally as a quick fix, the generated code is not affected.

(this is a strict conformance fix, future c standard may allow 1<<31,
see DR 463.  the bug was inherited from freebsd fdlibm, the proper fix
is to use uint32_t for all bit hacks, but that requires more intrusive
changes.)

reported by Daniel Sabogal

add union field that is used in the kernel for SIT/GRE tunneling ICMPv4
messages. see linux commit 20e1954fe238dbe5f8d3a979e593fe352bd703cf

another kernel internal state exposure for checkpoint-restore.
see linux commit b1ed4c4fa9a5ccf325184fd90edc50978ef6e33a

aarch64, arm, mips, mips64, mipsn32, powerpc, powerpc64 and sh have
cpu feature bits defined in linux for AT_HWCAP auxv entry, so expose
those in sys/auxv.h

it seems the mips hwcaps were never exposed to userspace neither
by linux nor by glibc, but that's most likely an oversight.

sync with gabi: http://www.sco.com/developers/gabi/latest/ch4.eheader.html

EM_BPF is new in linux v4.8 and officially assigned:
https://lists.iovisor.org/pipermail/iovisor-dev/2016-June/000266.html
added related relocs too.

see linux commit 6389eaa7fa9c3ee6c7d39f6087b86660d17236ac

sh was updated in linux commit 74bdaa611fa69368fb4032ad437af073d31116bd
to have numbers for new syscalls.

the numbers were wrong in musl, but they were also wrong in the kernel
and got fixed in v4.8 commit 3ebfd81f7fb3e81a754e37283b7f38c62244641a

overlayfs may have fairly long lines so we use getline to allocate a
buffer dynamically. The buffer will be allocated on first use, expand as
needed, but will never be free'ed.

Downstream bug: http://bugs.alpinelinux.org/issues/5703Signed-off-by: NNatanael Copa <ncopa@alpinelinux.org>

this patch fixes a large number of missed internal signed-overflow
checks and errors in determining when the return value (output length)
would exceed INT_MAX, which should result in EOVERFLOW. some of the
issues fixed were reported by Alexander Cherepanov; others were found
in subsequent review of the code.

aside from the signed overflows being undefined behavior, the
following specific bugs were found to exist in practice:

- overflows computing length of floating point formats with huge
  explicit precisions, integer formats with prefix characters and huge
  explicit precisions, or string arguments or format strings longer
  than INT_MAX, resulted in wrong return value and wrong %n results.

- literal width and precision values outside the range of int were
  misinterpreted, yielding wrong behavior in at least one well-defined
  case: string formats with precision greater than INT_MAX were
  sometimes truncated.

- in cases where EOVERFLOW is produced, incorrect values could be
  written for %n specifiers past the point of exceeding INT_MAX.

in addition to fixing these bugs, we now stop producing output
immediately when output length would exceed INT_MAX, rather than
continuing and returning an error only at the end.

if the requested precision is close to INT_MAX, adding
LDBL_MANT_DIG/3+8 overflows. in practice the resulting undefined
behavior manifests as a large negative result, which is then used to
compute the new end pointer (z) with a wildly out-of-bounds value
(more overflow, more undefined behavior). the end result is at least
incorrect output and character count (return value); worse things do
not seem to happen, but detailed analysis has not been done.

this patch fixes the overflow by performing the intermediate
computation as unsigned; after division by 9, the final result
necessarily fits in int.