this is enough to produce the correct value even if the constant is
interpreted as 80-bit extended precision, which matters on archs with
excess precision (FLT_EVAL_METHOD==2) under at least some
interpretations of the C standard. the shorter representations, while
correct if converted to the nominal precision at translation time,
could produce an incorrect value at extended precision, yielding
results such as (double)DBL_MAX != DBL_MAX.
siginfo_t is not available from signal.h when the strict ISO C feature
profile (e.g. passing -std=c99 to gcc without defining any other
feature test macros) is used, but the type is needed to declare
waitid. using sys/wait.h (or any POSIX headers) in strict ISO C mode
is an application bug, but in the interest of compatibility, it's best
to avoid producing gratuitous errors. the simplest fix I could find is
suppressing the declaration of waitid (and also signal.h inclusion,
since it's not needed for anything else) in this case, while still
exposing everything else in sys/wait.h
while using "l" unconditionally gave the right behavior due to
matching sizes/representations, it was technically UB and produced
compiler warnings with format string checking.
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.
fcntl.h: AT_* is not a reserved namespace so extensions cannot be
exposed by default.
langinfo.h: YESSTR and NOSTR were removed from the standard.
limits.h: NL_NMAX was removed from the standard.
signal.h: the conditional for NSIG was wrongly checking _XOPEN_SOURCE
rather than _BSD_SOURCE. this was purely a mistake; it doesn't even
match the commit message from the commit that added it.
This is a change in ISO C11 annex F (F.10.11p1), comparision macros
can't round their arguments to their semantic type when the evaluation
format has wider range and precision. (ie. they must be consistent with
the builtin relational operators)
These constants are not specified by POSIX, but they are in the reserved
namespace, glibc and bsd systems seem to provide them as well.
(Note that POSIX specifies -NZERO and NZERO-1 to be the limits, but
PRIO_MAX equals NZERO)
the changes were verified using various sources:
linux: include/uapi/linux/elf.h
binutils: include/elf/common.h
glibc: elf/elf.h
sysv gabi: http://www.sco.com/developers/gabi/latest/contents.html
sun linker docs: http://docs.oracle.com/cd/E18752_01/pdf/817-1984.pdf
and platform specific docs
- fixed:
EF_MIPS_* E_MIPS_* e_flags: fixed accoding to glibc and binutils
- added:
ELFOSABI_GNU for EI_OSABI entry: glibc, binutils and sysv gabi
EM_* e_machine values: updated according to linux and glibc
PN_XNUM e_phnum value: from glibc and linux, see oracle docs
NT_* note types: updated according to linux and glibc
DF_1_* flags for DT_FLAGS_1 entry: following glibc and oracle docs
AT_HWCAP2 auxv entry for more hwcap bits accoding to linux and glibc
R_386_SIZE32 relocation according to glibc and binutils
EF_ARM_ABI_FLOAT_* e_flags: added following glibc and binutils
R_AARCH64_* relocs: added following glibc and aarch64 elf specs
R_ARM_* relocs: according to glibc, binutils and arm elf specs
R_X86_64_* relocs: added missing relocs following glibc
- removed:
HWCAP_SPARC_* flags were moved to arch specific header in glibc
R_ARM_SWI24 reloc is marked as obsolete in glibc, not present in binutils
not specified in arm elf spec, R_ARM_TLS_DESC reused its number
see http://www.codesourcery.com/publications/RFC-TLSDESC-ARM.txt
- glibc changes not pulled in:
ELFOSABI_ARM_AEABI (bare-metal system, binutils and glibc disagrees about the name)
R_68K_* relocs for unsupported platform
R_SPARC_* ditto
EF_SH* ditto (e_flags)
EF_S390* ditto (e_flags)
R_390* ditto
R_MN10300* ditto
R_TILE* ditto
the removed ARPHRD_IEEE802154_PHY was only present in the kernel api
in v2.6.31 (by accident), but it got into the glibc headers (in 2009)
and remained there since this header was not updated since then.
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 BSD and GNU versions of this structure differ, so exposing it in
the default _BSD_SOURCE profile is possibly problematic. both versions
could be simultaneously supported with anonymous unions if needed in
the future, but for now, just omitting it except under _GNU_SOURCE
should be safe.
while the incorporation of this requirement from C99 into C++11 was
likely an accident, some software expects it to be defined, and it
doesn't hurt. if the requirement is removed, then presumably
__bool_true_false_are_defined would just be in the implementation
namespace and thus defining it would still be legal.
the duplicate code in dn_expand and its incorrect return values are
both results of the history of the code: the version in __dns.c was
originally written with no awareness of the legacy resolver API, and
was later copy-and-paste duplicated to provide the legacy API.
this commit is the first of a series that will restructure the
internal dns code to share as much code as possible with the legacy
resolver API functions.
I have also removed the loop detection logic, since the output buffer
length limit naturally prevents loops. in order to avoid long runtime
when encountering a loop if the caller provided a ridiculously long
buffer, the caller-provided length is clamped at the maximum dns name
length.
these aliases were originally intended to be for ABI compatibility
only, but their presence caused regressions in broken gnulib-based
software whose configure scripts detect the existing of these
functions then use them without declarations, resulting in bogus
return values.
mips has signal numbers up to 127 (formerly, up to 128, but the last
one never worked right and caused kernel panic when used), so 127 in
the "signal number" field of the wait status is insufficient for
determining that the process was stopped. in addition, a nonzero value
in the upper bits must be present, indicating the signal number which
caused the process to be stopped.
details on this issue can be seen in the email with message id
CAAG0J9-d4BfEhbQovFqUAJ3QoOuXScrpsY1y95PrEPxA5DWedQ@mail.gmail.com on
the linux-mips mailing list, archived at:
http://www.linux-mips.org/archives/linux-mips/2013-06/msg00552.html
and in the associated thread about fixing the mips kernel bug.
commit 4a96b948687166da26a6c327e6c6733ad2336c5c fixed the
corresponding issue in uClibc, but introduced a multiple-evaluation
issue for the WIFSTOPPED macro.
for the most part, none of these issues affected pure musl systems,
since musl has up until now (incorrectly) defined SIGRTMAX as 64 on
all archs, even mips. however, interpreting status of non-musl
programs on mips may have caused problems. with this change, the full
range of signal numbers can be made available on mips.
this first commit just includes the CPU_* and sched_* interfaces, not
the pthread_* interfaces, which may be added later. simple
sanity-check testing has been done for the basic interfaces, but most
of the macros have not yet been tested.
also add a warning to the existing sys/poll.h. the warning is absent
from sys/dir.h because it is actually providing a slightly different
API to the program, and thus just replacing the #include directive is
not a valid fix to programs using this one.
apparently the original kernel commit's i386 version of siginfo.h
defined this field as unsigned int, but the asm-generic file always
had void *. unsigned int is obviously not a suitable type for an
address, in a non-arch-specific file, and glibc also has void * here,
so I think void * is the right type for it.
also fix redundant type specifiers.
Michael Forney
Szabolcs Nagy
Timo Teräs
rofl0r
Rich Felker