gcc -Wsign-compare warns about expanded macros that were defined in
standard headers (before gcc 4.8) which can make builds fail that
use -Werror. changed macros: WIFSIGNALED, __CPU_op_S
the affected part of the header is responsible for providing both GNU
and BSD versions of the udphdr structure. previously, the
namespace-polluting GNU names were always used for the actual struct
members, and the BSD names, which are named in a manner resembling a
sane namespace, were always macros defined to expand to the GNU names.
now, unless _GNU_SOURCE is defined, the BSD names are used as the
actual structure members, and the macros and GNU names only come into
play when the application requests them.
there are two versions of this structure: the BSD version and the GNU
version. previously only the GNU version was supported. the only way
to support both simultaneously is with an anonymous union, which was a
nonstandard extension prior to C11, so some effort is made to avoid
breakage with compilers which do not support anonymous unions.
this commit is based on a patch by Timo Teräs, but with some changes.
in particular, the GNU version of the structure is not exposed unless
_GNU_SOURCE is defined; this both avoids namespace pollution and
dependency on anonymous unions in the default feature profile.
these are poorly designed (illogical argument order) and even poorly
implemented (brace issues) on glibc, but unfortunately some software
is using them. we could consider removing them again in the future at
some point if they're documented as deprecated, but for now the
simplest thing to do is just to provide them under _GNU_SOURCE.
some applications expect it to be defined, despite the standard making
it impossible for it to ever be returned as a value distinct from
NO_DATA. since these macros are outside the scope of the current
standards, no special effort is made to hide NO_ADDRESS under
conditions where the others are exposed.
in fixing this, I've changed the logic from ugly #if/#else blocks
inside the struct shm_info definition to a fixed struct definition and
optional macros to rename the elements. this will be helpful if we
need to move shm_info to a bits header in the future, as it will keep
the feature test logic out of bits.
the imr_, imsf_, ip6_, ip6m_, ipi_, ipi6_, SCM_, and SOL_ prefixes are
not in the reserved namespace for this header. thus the constants and
structures using them need to be protected under appropriate feature
test macros.
this also affects some headers which are permitted to include
netinet/in.h, particularly netdb.h and arpa/inet.h.
the SOL_ macros are moved to sys/socket.h where they are in the
reserved namespace (SO*). they are still accessible via netinet/in.h
since it includes sys/socket.h implicitly (which is permitted).
the SCM_SRCRT macro is simply removed, since the definition used for
it, IPV6_RXSRCRT is not defined anywhere. it could be re-added, this
time in sys/socket.h, if the appropriate value can be determined;
however, given that the erroneous definition was not caught, it is
unlikely that any software actually attempts to use SCM_SRCRT.
it's unclear what the historical signature for this function was, but
semantically, the argument should be a pointer to const, and this is
what glibc uses. correct programs should not be using this function
anyway, so it's unlikely to matter.
this change is consistent with the corresponding glibc functions and
is semantically const-correct. the incorrect argument types without
const seem to have been taken from erroneous man pages.
this functionality has essentially always been deprecated in linux,
and was never supported by musl. the presence of the header was
reported to cause some software to attempt to use the nonexistant
function, so removing the header is the cleanest solution.
this was wrong since the original commit adding inotify, and I don't
see any explanation for it. not even the man pages have it wrong. it
was most likely a copy-and-paste error.
this agrees with implementation practice on glibc and BSD systems, and
is the const-correct way to do things; it eliminates warnings from
passing pointers to const. the prototype without const came from
seemingly erroneous man pages.
ssi_ptr is really 64-bit in kernel, so fix that. assuming sizeof(void*)
for it also caused incorrect padding for 32-bits, as the following
64-bits are aligned to 64-bits (and the padding was not taken into
account), so fix the padding as well. add addr_lsb field while there.
historically these functions appeared in BSD 4.3 without prototypes,
then in the bind project prototypes were added to resolv.h, but those
were incompatible with the definitions of the implementation.
the bind resolv.h became the defacto api most systems use now, but the
old internal definitions found their way into the linux manuals and thus
into musl.
the old value of 20 was reported by Laurent Bercot as being
insufficient for a reasonable real-world usage case. actual problem
was the internal buffer used by ttyname(), but the implementation of
ttyname uses TTY_NAME_MAX, and for consistency it's best to increase
both. the new value is aligned with glibc.
on archs with excess precision, the floating point constant 1e40f may
be evaluated such that it does not actually produce an infinity.
1e5000f is sufficiently large to produce an infinity for all supported
floating point formats. note that this definition of INFINITY is only
used for old or non-GNUC compilers anyway; despite being a portable,
conforming definition, it leads to erroneous warnings on many
compilers and thus using the builtin is preferred.
unfortunately this eliminates the ability of the compiler to diagnose
some dangerous/incorrect usage, but POSIX requires (as an extension to
the C language, i.e. CX shaded) that NULL have type void *. plain C
allows it to be defined as any null pointer constant.
the definition 0L is preserved for C++ rather than reverting to plain
0 to avoid dangerous behavior in non-conforming programs which use
NULL as a variadic sentinel. (it's impossible to use (void *)0 for C++
since C++ lacks the proper implicit pointer conversions, and other
popular alternatives like the GCC __null extension seem non-conforming
to the standard's requirements.)
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.
linux commit 8d36eb01da5d371feffa280e501377b5c450f5a5 (2013-05-29)
added PF_IB for InfiniBand
linux commit d021c344051af91f42c5ba9fdedc176740cbd238 (2013-02-06)
added PF_VSOCK for VMware sockets
linux commit a0727e8ce513fe6890416da960181ceb10fbfae6 (2012-04-12)
added siginfo fields for SIGSYS (seccomp uses it)
linux commit ad5fa913991e9e0f122b021e882b0d50051fbdbc (2009-09-16)
added siginfo field and si_code values for SIGBUS (hwpoison signal)
this is necessary to meet the C++ ABI target. alternatives were
considered to avoid the size increase for non-sig jmp_buf objects, but
they seemed to have worse properties. moreover, the relative size
increase is only extreme on x86[_64]; one way of interpreting this is
that, if the size increase from this patch makes jmp_buf use too much
memory, then the program was already using too much memory when built
for non-x86 archs.
this patch is something of a compromise for a compatibility
regression discovered after the header refactoring: libtiff uses
_Int64 for its own use. this is absolutely wrong, invalid C, and
should not be supported, but it's also frustrating for users when code
that used to work suddenly breaks.
rather than leave the breakage in place or change musl internals to
accommodate broken software, I've found a change that makes the
problem go away and improves musl. by undefining these macros at the
end of alltypes.h, the temptation to use them in other headers is
removed. (for example, I almost used _Int64 in sys/types.h to define
u_int64_t rather than adding it back to alltypes.h.) by confining use
of these macros to alltypes.h, we keep it easy to go back and change
the implementation of alltypes later, if needed.
during the header refactoring, I had moved u_int64_t out of alltypes
under the assumption that we could just use long long everywhere.
however, it seems some broken applications make inconsistent mixed use
of u_int64_t and uint64_t, resulting in build errors when the
underlying type differs.
rather than moving nlink_t back to the arch-specific file, I've added
a macro _Reg defined to the canonical type for register-size values on
the arch. this is not the same as _Addr for (not-yet-supported)
32-on-64 pseudo-archs like x32 and mips n32, so a new macro was
needed.
for regoff_t, it's impossible to match on 64-bit archs because glibc
defined the type in a non-conforming way. however this change makes
the type match on 32-bit archs.
aside from the obvious C++ ABI purpose for this change, it also brings
musl into alignment with the compiler's idea of the definition of
wint_t (use in -Wformat), and makes the situation less awkward on ARM,
where wchar_t is unsigned.
internal code using wint_t and WEOF was checked against this change,
and while a few cases of storing WEOF into wchar_t were found, they
all seem to operate properly with the natural conversion from unsigned
to signed.
the arch-specific bits/alltypes.h.sh has been replaced with a generic
alltypes.h.in and minimal arch-specific bits/alltypes.h.in.
this commit is intended to have no functional changes except:
- exposing additional symbols that POSIX allows but does not require
- changing the C++ name mangling for some types
- fixing the signedness of blksize_t on powerpc (POSIX requires signed)
- fixing the limit macros for sig_atomic_t on x86_64
- making dev_t an unsigned type (ABI matching goal, and more logical)
in addition, some types that were wrongly defined with long on 32-bit
archs were changed to int, and vice versa; this change is
non-functional except for the possibility of making pointer types
mismatch, and only affects programs that were using them incorrectly,
and only at build-time, not runtime.
the following changes were made in the interest of moving
non-arch-specific types out of the alltypes system and into the
headers they're associated with, and also will tend to improve
application compatibility:
- netdb.h now includes netinet/in.h (for socklen_t and uint32_t)
- netinet/in.h now includes sys/socket.h and inttypes.h
- sys/resource.h now includes sys/time.h (for struct timeval)
- sys/wait.h now includes signal.h (for siginfo_t)
- langinfo.h now includes nl_types.h (for nl_item)
for the types in stdint.h:
- types which are of no interest to other headers were moved out of
the alltypes system.
- fast types for 8- and 64-bit are hard-coded (at least for now); only
the 16- and 32-bit ones have reason to vary by arch.
and the following types have been changed for C++ ABI purposes;
- mbstate_t now has a struct tag, __mbstate_t
- FILE's struct tag has been changed to _IO_FILE
- DIR's struct tag has been changed to __dirstream
- locale_t's struct tag has been changed to __locale_struct
- pthread_t is defined as unsigned long in C++ mode only
- fpos_t now has a struct tag, _G_fpos64_t
- fsid_t's struct tag has been changed to __fsid_t
- idtype_t has been made an enum type (also required by POSIX)
- nl_catd has been changed from long to void *
- siginfo_t's struct tag has been removed
- sigset_t's has been given a struct tag, __sigset_t
- stack_t has been given a struct tag, sigaltstack
- suseconds_t has been changed to long on 32-bit archs
- [u]intptr_t have been changed from long to int rank on 32-bit archs
- dev_t has been made unsigned
summary of tests that have been performed against these changes:
- nsz's libc-test (diff -u before and after)
- C++ ABI check symbol dump (diff -u before, after, glibc)
- grepped for __NEED, made sure types needed are still in alltypes
- built gcc 3.4.6
while there's no POSIX namespace provision for UIO_* in uio.h, this
exact macro name is reserved in XBD 2.2.2. apparently some
glibc-centric software expects it to exist, so let's provide it.
POSIX is not clear on whether it includes the termination, but ISO C
requires that it does. the whole concept of this macro is rather
useless, but it's better to be correct anyway.
the main use for this macro seems to be knowing the correct allocation
granularity for dynamic-sized fd_set objects. such usage is
non-conforming and results in undefined behavior, but it is widespread
in applications.
a research in debian codesearch and grepping over the pkgsrc
directory tree have shown that these macros are all either unused,
or defined by programs in case they need them.
these would not be expensive to actually implement, but reading
/etc/ethers does not sound like a particularly useful feature, so for
now I'm leaving them as stubs.
in theory this should not be an issue, since major() should only be
applied to type dev_t, which is 64-bit. however, it appears some
applications are not using dev_t but a smaller integer type (which
works on Linux because the kernel's dev_t is really only 32-bit). to
avoid the undefined behavior, do it as two shifts.
rejecting invalid values for n is fine even in the case where a new
sem will not be created, since the kernel does its range checks on n
even in this case as well.
by default, the kernel will bound the limit well below USHRT_MAX
anyway, but it's presumably possible that an administrator could
override this limit and break things.
this type is not really intended to be used; it's just there to allow
implementations to choose the type for the shm_nattch member of
struct shmid_sh, presumably since historical implementations disagreed
on the type. in any case, it needs to be there, so now it is.
the pathnames prefixed with /dev/null/ are guaranteed never to be
valid. the previous use of /dev/null alone was mildly dangerous in
that bad software might attempt to unlink the name when it found a
non-regular file there and create a new file.
despite declaring functions that take arguments of type va_list, these
headers are not permitted by the c standard to expose the definition
of va_list, so an alias for the type must be used. the name
__isoc_va_list was chosen to convey that the purpose of this alternate
name is for iso c conformance, and to avoid the multitude of names
which gcc mangles with its hideous "fixincludes" monstrosity, leading
to serious header breakage if these "fixes" are run.
also move all legacy inet_* functions into a single file to avoid
wasting object file and compile time overhead on them.
the added functions are legacy interfaces for working with classful
ipv4 network addresses. they have no modern usefulness whatsoever, but
some programs unconditionally use them anyway, and they're tiny.
based on patch by Strake with minor stylistic changes, and combined
into a single file. this patch remained open for a long time due to
some question as to whether ether_aton would be better implemented in
terms of sscanf, and it's time something was committed, so here it is.
arguably CLOCK_MONOTONIC should be redirected to CLOCK_BOOTTIME with a
fallback for old kernels that don't support it, since Linux's
CLOCK_BOOTTIME semantics seem to match the spirit of the POSIX
requirements for CLOCK_MONOTONIC better than Linux's version of
CLOCK_MONOTONIC does. however, this is a change that would require
further discussion and research, so for now, I'm simply making them
all available.
originally it was right on 32-bit archs and wrong on 64-bit, but after
recent changes it was wrong everywhere. with this commit, it's now
right everywhere.
there was some question as to how many decimal places to use, since
one decimal place is always sufficient to identify the smallest
denormal uniquely. for now, I'm following the example in the C
standard which is consistent with the other min/max macros we already
had in place.
somehow I missed this when removing the corresponding
__STDC_LIMIT_MACROS and __STDC_CONSTANT_MACROS nonsense from stdint.h.
these were all attempts by the C committee to guess what the C++
committee would want, and the guesses turned out to be wrong.
__FLOAT_BITS and __DOUBLE_BITS macros used union compound literals,
now they are changed into static inline functions. A good C compiler
generates the same code for both and the later is C++ conformant.
C++11, the first C++ with stdint.h, requires the previously protected
macros to be exposed unconditionally by stdint.h. apparently these
checks were an early attempt by the C committee to guess what the C++
committee would want, and they guessed wrong.
the getifaddrs interface seems to have been invented by glibc, and
they expose socket.h, so for us not to do so is just gratuitous
incompatibility with the interface we're mimicing.
this is a bit ugly, and the motivation for supporting it is
questionable. however the main factors were:
1. it will be useful to have this for certain internal purposes
anyway -- things like syslog.
2. applications can just save argv[0] in main, but it's hard to fix
non-portable library code that's depending on being able to get the
invocation name without the main application's help.
supports ipv4 and ipv6, but not the "extended" usage where
usage statistics and other info are assigned to ifa_data members
of duplicate entries with AF_PACKET family.
the preprocessor can reliably determine the signedness of wchar_t.
L'\0' is used for 0 in the expressions so that, if the underlying type
of wchar_t is long rather than int, the promoted type of the
expression will match the type of wchar_t.
since shadow does not yet support enumeration (getspent), the
corresponding FILE-based get and put versions are also subbed out for
now. this is partly out of laziness and partly because it's not clear
how they should work in the presence of TCB shadow files. the stubs
should make it possible to compile some software that expects them to
exist, but such software still may not work properly.
this type was removed back in 5243e5f1606a9c6fcf01414e ,
because it was removed from the XSI specs.
however some apps use it.
since it's in the POSIX reserved namespace, we can expose it
unconditionally.
this fix is far from ideal and breaks the rule of not using
arch-specific #ifdefs, but for now we just need a solution to the
existing breakage.
the underlying problem is that the kernel folks made a very stupid
decision to make misalignment of this struct part of the kernel
API/ABI for x86_64, in order to avoid writing a few extra lines of
code to handle both 32- and 64-bit userspace on 64-bit kernels. I had
just added the packed attribute unconditionally thinking it was
harmless on 32-bit archs, but non-x86 32-bit archs have 8-byte
alignment on 64-bit types.
