this attribute was applied to pthread_self and the functions providing
the locations for errno and h_errno as an optimization; however, it is
subtly incorrect. as specified, it means the return value will always
be the same, which is not true; it varies per-thread.
this attribute also implies that the function does not depend on any
state, and that calls to it can safely be reordered across any other
code. however such reordering is unsafe for these functions: they
break when reordered before initialization of the thread pointer. such
breakage was actually observed when compiled by libfirm/cparser.
to some extent the reordering problem could be solved with strong
compiler barriers between the stages of early startup code, but the
specified meaning of of attribute((const)) is sufficiently strong that
a compiler would theoretically be justified inserting gratuitous calls
to attribute((const)) const functions at random locations (e.g. to
save the value in static storage for later use).
this reverts commit cbf35978a9.
their absence completely breaks format string warnings in programs
with gettext message translations: -Wformat gives no results, and
-Wformat-nonliteral produces spurious warnings.
with gcc, the problem manifests only in standards-conforming profiles;
otherwise gcc sets these attributes by default for the gettext family.
with clang, the problem always manifests; clang has no such defaults.
being nonstandard, the closest thing to a specification for this
function is its man page, which documents it as returning int. it can
fail with EBADF if the file descriptor passed is invalid.
this patch activates the new byte-based C locale (high bytes treated
as abstract code unit "characters" rather than decoded as multibyte
characters) by making the value of MB_CUR_MAX depend on the active
locale. for the C locale, the LC_CTYPE category pointer is null,
yielding a value of 1. all other locales yield a value of 4.
the casts of the argument to unsigned int suppressed diagnosis of
errors like passing a pointer instead of a character. putting the
actual function call in an unreachable branch restores any diagnostics
that would be present if the macros didn't exist and functions were
used.
the C standard specifies that setjmp is a macro, but longjmp is a
normal function. a macro version of it would be permitted (albeit
useless) for C (not C++), but would have to be a function-like macro,
not an object-like one.
while it's the same for all presently supported archs, it differs at
least on sparc, and conceptually it's no less arch-specific than the
other O_* macros. O_SEARCH and O_EXEC are still defined in terms of
O_PATH in the main fcntl.h.
commit 559de8f5f0 redefined FLT_ROUNDS
to use an external function that can report the actual current
rounding mode, rather than always reporting round-to-nearest. however,
float.h did not include 'extern "C"' wrapping for C++, so C++ programs
using FLT_ROUNDS ended up with an unresolved reference to a
name-mangled C++ function __flt_rounds.
the previous values (2k min and 8k default) were too small for some
archs. aarch64 reserves 4k in the signal context for future extensions
and requires about 4.5k total, and powerpc reportedly uses over 2k.
the new minimums are chosen to fit the saved context and also allow a
minimal signal handler to run.
since the default (SIGSTKSZ) has always been 6k larger than the
minimum, it is also increased to maintain the 6k usable by the signal
handler. this happens to be able to store one pathname buffer and
should be sufficient for calling any function in libc that doesn't
involve conversion between floating point and decimal representations.
x86 (both 32-bit and 64-bit variants) may also need a larger minimum
(around 2.5k) in the future to support avx-512, but the values on
these archs are left alone for now pending further analysis.
the value for PTHREAD_STACK_MIN is not increased to match MINSIGSTKSZ
at this time. this is so as not to preclude applications from using
extremely small thread stacks when they know they will not be handling
signals. unfortunately cancellation and multi-threaded set*id() use
signals as an implementation detail and therefore require a stack
large enough for a signal context, so applications which use extremely
small thread stacks may still need to avoid using these features.
normally time.h would provide a definition for this struct, but
depending on the feature test macros in use, it may not be exposed,
leading to warnings when it's used in the function prototypes.
these macros have the same distinct definition on blackfin, frv, m68k,
mips, sparc and xtensa kernels. POLLMSG and POLLRDHUP additionally
differ on sparc.
the memory model we use internally for atomics permits plain loads of
values which may be subject to concurrent modification without
requiring that a special load function be used. since a compiler is
free to make transformations that alter the number of loads or the way
in which loads are performed, the compiler is theoretically free to
break this usage. the most obvious concern is with atomic cas
constructs: something of the form tmp=*p;a_cas(p,tmp,f(tmp)); could be
transformed to a_cas(p,*p,f(*p)); where the latter is intended to show
multiple loads of *p whose resulting values might fail to be equal;
this would break the atomicity of the whole operation. but even more
fundamental breakage is possible.
with the changes being made now, objects that may be modified by
atomics are modeled as volatile, and the atomic operations performed
on them by other threads are modeled as asynchronous stores by
hardware which happens to be acting on the request of another thread.
such modeling of course does not itself address memory synchronization
between cores/cpus, but that aspect was already handled. this all
seems less than ideal, but it's the best we can do without mandating a
C11 compiler and using the C11 model for atomics.
in the case of pthread_once_t, the ABI type of the underlying object
is not volatile-qualified. so we are assuming that accessing the
object through a volatile-qualified lvalue via casts yields volatile
access semantics. the language of the C standard is somewhat unclear
on this matter, but this is an assumption the linux kernel also makes,
and seems to be the correct interpretation of the standard.
this is a new extension which is presently intended only for
experimental and internal libc use. interface and behavior details may
change subject to feedback and experience from using it internally.
the basic concept for the new PTHREAD_CANCEL_MASKED state is that the
first cancellation point to observe the cancellation request fails
with an errno value of ECANCELED rather than acting on cancellation,
allowing the caller to process the status and choose whether/how to
act upon it.
these socket options are new in linux v3.19, introduced in commit
2c8c56e15df3d4c2af3d656e44feb18789f75837 and commit
89aa075832b0da4402acebd698d0411dcc82d03e
with SO_INCOMING_CPU the cpu can be queried on which a socket is
managed inside the kernel and optimize polling of large number of
sockets accordingly.
SO_ATTACH_BPF lets eBPF programs (created by the bpf syscall) to
be attached to sockets.
the definitions are generic for all kernel archs. exposure of these
macros now only occurs on the same feature test as for the function
accepting them, which is believed to be more correct.
PR_SET_MM_MAP was introduced as a subcommand for PR_SET_MM in
linux v3.18 commit f606b77f1a9e362451aca8f81d8f36a3a112139e
the associated struct type is replicated in sys/prctl.h using
libc types.
example usage:
struct prctl_mm_map *p;
...
prctl(PR_SET_MM, PR_SET_MM_MAP, p, sizeof *p);
the kernel side supported struct size may be queried with
the PR_SET_MM_MAP_SIZE subcommand.
per the rules for hexadecimal integer constants, the previous
definitions were correctly treated as having unsigned type except
possibly when used in preprocessor conditionals, where all artithmetic
takes place as intmax_t or uintmax_t. the explicit 'u' suffix ensures
that they are treated as unsigned in all contexts.
it's unclear whether compilers which provide pure imaginary types
might produce a pure imaginary expression for 1.0fi. using 0.0f+1.0fi
ensures that the result is explicitly complex and makes this obvious
to human readers too.
based on patches by Jens Gustedt. these macros need to be usable in
static initializers, and the old definitions were not.
there is no portable way to provide correct definitions for these
macros unless the compiler supports pure imaginary types. a portable
definition is provided for this case even though there are presently
no compilers that can use it. gcc and compatible compilers provide a
builtin function that can be used, but clang fails to support this and
instead requires a construct which is a constraint violation and which
is only a constant expression as a clang-specific extension.
since these macros are a namespace violation in pre-C11 profiles, and
since no known pre-C11 compilers provide any way to define them
correctly anyway, the definitions have been made conditional on C11.
based on patch by Timo Teräs, with some corrections to bounds checking
code and other minor changes.
while they are borderline scope creep, the functions added are fairly
small and are roughly the minimum code needed to use the results of
the res_query API without re-implementing error-prone DNS packet
parsing, and they are used in practice by some kerberos related
software and possibly other things. at this time there is no intent to
implement further nameser.h API functions.
C++ programmers typically expect something like "::function(x,y)" to work
and may be surprised to find that "(::function)(x,y)" is actually required
due to the headers declaring a macro version of some standard functions.
We already omit function-like macros for C++ in most cases where there is
a real function available. This commit extends this to the remaining
function-like macros which have a real function version.
new in linux v3.17 commit 40e041a2c858b3caefc757e26cb85bfceae5062b
sealing allows some operations to be blocked on a file which makes
file access safer when fds are shared between processes (only
supported for shared mem fds currently)
flags:
F_SEAL_SEAL prevents further sealing
F_SEAL_SHRINK prevents file from shrinking
F_SEAL_GROW prevents file from growing
F_SEAL_WRITE prevents writes
fcntl commands:
F_GET_SEALS get the current seal flags
F_ADD_SEALS add new seal flags
as a result of commit ab8f6a6e42, this
definition is now equivalent to the actual "default profile" which
appears immediately below in features.h, and which defines both
_BSD_SOURCE and _XOPEN_SOURCE.
the intent of providing a _DEFAULT_SOURCE, which glibc also now
provides, is to give applications a way to "get back" the default
feature profile when it was lost either by compiler flags that inhibit
it (such as -std=c99) or by library-provided predefined macros (such
as -D_POSIX_C_SOURCE=200809L) which may inhibit exposure of features
that were otherwise visible by default and which the application may
need. without _DEFAULT_SOURCE, the application had encode knowledge of
a particular libc's defaults, and such knowledge was fragile and
subject to bitrot.
eventually the names _GNU_SOURCE and _BSD_SOURCE should be phased out
in favor of the more-descriptive and more-accurate _ALL_SOURCE and
_DEFAULT_SOURCE, leaving the old names as aliases but using the new
ones internally. however this is a more invasive change that would
require extensive regression testing, so it is deferred.
the vast majority of these failures seem to have been oversights at
the time _BSD_SOURCE was added, or perhaps shortly afterward. the one
which may have had some reason behind it is omission of setpgrp from
the _BSD_SOURCE feature profile, since the standard setpgrp interface
conflicts with a legacy (pre-POSIX) BSD interface by the same name.
however, such omission is not aligned with our general policy in this
area (for example, handling of similar _GNU_SOURCE cases) and should
not be preserved.
open file description locks are inherited across fork and only auto
dropped after the last fd of the file description is closed, they can be
used to synchronize between threads that open separate file descriptions
for the same file.
new in linux 3.15 commit 0d3f7a2dd2f5cf9642982515e020c1aee2cf7af6
based on patch by Jens Gustedt.
mtx_t and cnd_t are defined in such a way that they are formally
"compatible types" with pthread_mutex_t and pthread_cond_t,
respectively, when accessed from a different translation unit. this
makes it possible to implement the C11 functions using the pthread
functions (which will dereference them with the pthread types) without
having to use the same types, which would necessitate either namespace
violations (exposing pthread type names in threads.h) or incompatible
changes to the C++ name mangling ABI for the pthread types.
for the rest of the types, things are much simpler; using identical
types is possible without any namespace considerations.
there is no blksize64_t (blksize_t is always long) but there are
fsblkcnt64_t and fsfilcnt64_t types in sys/stat.h and sys/types.h.
and glob.h missed glob64_t.
this function is needed for some important practical applications of
ABI compatibility, and may be useful for supporting some non-portable
software at the source level too.
I was hesitant to add a function which imposes any constraints on
malloc internals; however, it turns out that any malloc implementation
which has realloc must already have an efficient way to determine the
size of existing allocations, so no additional constraint is imposed.
for now, some internal malloc definitions are duplicated in the new
source file. if/when malloc is refactored to put them in a shared
internal header file, these could be removed.
since malloc_usable_size is conventionally declared in malloc.h, the
empty stub version of this file was no longer suitable. it's updated
to provide the standard allocator functions, nonstandard ones (even if
stdlib.h would not expose them based on the feature test macros in
effect), and any malloc-extension functions provided (currently, only
malloc_usable_size).
unfortunately this needs to be able to vary by arch, because of a huge
mess GCC made: the GCC definition, which became the ABI, depends on
quirks in GCC's definition of __alignof__, which does not match the
formal alignment of the type.
GCC's __alignof__ unexpectedly exposes the an implementation detail,
its "preferred alignment" for the type, rather than the formal/ABI
alignment of the type, which it only actually uses in structures. on
most archs the two values are the same, but on some (at least i386)
the preferred alignment is greater than the ABI alignment.
I considered using _Alignas(8) unconditionally, but on at least one
arch (or1k), the alignment of max_align_t with GCC's definition is
only 4 (even the "preferred alignment" for these types is only 4).
ETH_P_80221 is ethertype for IEEE Std 802.21 - Media Independent Handover Protocol
introduced in linux 3.15 commit b62faf3cdc875a1ac5a10696cf6ea0b12bab1596
ETH_P_LOOPBACK is the correct packet type for loopback in IEEE 802.3*
introduced in linux 3.15 commit 61ccbb684421d374fdcd7cf5d6b024b06f03ce4e
some defines were shuffled to be in ascending order and match the kernel header
this function provides a way for third-party library code to use the
same logic that's used internally in libc for suppressing untrusted
input/state (e.g. the environment) when the application is running
with privleges elevated by the setuid or setgid bit or some other
mechanism. its semantics are intended to match the openbsd function by
the same name.
there was some question as to whether this function is necessary:
getauxval(AT_SECURE) was proposed as an alternative. however, this has
several drawbacks. the most obvious is that it asks programmers to be
aware of an implementation detail of ELF-based systems (the aux
vector) rather than simply the semantic predicate to be checked. and
trying to write a safe, reliable version of issetugid in terms of
getauxval is difficult. for example, early versions of the glibc
getauxval did not report ENOENT, which could lead to false negatives
if AT_SECURE was not present in the aux vector (this could probably
only happen when running on non-linux kernels under linux emulation,
since glibc does not support linux versions old enough to lack
AT_SECURE). as for musl, getauxval has always properly reported
errors, but prior to commit 7bece9c209,
the musl implementation did not emulate AT_SECURE if missing, which
would result in a false positive. since musl actually does partially
support kernels that lack AT_SECURE, this was problematic.
the intent is that library authors will use issetugid if its
availability is detected at build time, and only fall back to the
unreliable alternatives on systems that lack it.
patch by Brent Cook. commit message/rationale by Rich Felker.
With the exception of a fenv implementation, the port is fully featured.
The port has been tested in or1ksim, the golden reference functional
simulator for OpenRISC 1000.
It passes all libc-test tests (except the math tests that
requires a fenv implementation).
The port assumes an or1k implementation that has support for
atomic instructions (l.lwa/l.swa).
Although it passes all the libc-test tests, the port is still
in an experimental state, and has yet experienced very little
'real-world' use.
this issue affected the prioritynames and facilitynames arrays which
are only provided when requested (usually by syslogd implementations)
and which are presently defined as compound literals. the aliasing
violation seems to have been introduced as a workaround for bad
behavior by gcc's -Wwrite-strings option, but it caused compilers to
completely optimize out the contents of prioritynames and
facilitynames since, under many usage cases, the aliasing rules prove
that the contents are never accessed.
these are not pure syscall wrappers because they have to work around
kernel API bugs on 64-bit archs. the workarounds could probably be
made somewhat more efficient, but at the cost of more complexity. this
may be revisited later.
for all address types, a scope_id specified as a decimal value is
accepted. for addresses with link-local scope, a string containing the
interface name is also accepted.
some changes are made to error handling to avoid unwanted fallbacks in
the case where the scope_id is invalid: if an earlier name lookup
backend fails with an error rather than simply "0 results", this
failure now suppresses any later attempts with other backends.
in getnameinfo, a light "itoa" type function is added for generating
decimal scope_id results, and decimal port strings for services are
also generated using this function now so as not to pull in the
dependency on snprintf.
in netdb.h, a definition for the NI_NUMERICSCOPE flag is added. this
is required by POSIX (it was previously missing) and needed to allow
callers to suppress interface-name lookups.
from linux/in.h and linux/in6.h uapi headers the following
missing socket options were added:
IP_NODEFRAG - used with customized ipv4 headers
IPV6_RECVPATHMTU - for ipv6 path mtu
IPV6_PATHMTU - for ipv6 path mtu
IPV6_DONTFRAG - for ipv6 path mtu
IPV6_ADDR_PREFERENCES - RFC5014 Source Address Selection
IPV6_MINHOPCOUNT - RFC5082 Generalized TTL Security Mechanism
IPV6_ORIGDSTADDR - used by tproxy
IPV6_RECVORIGDSTADDR - used by tproxy
IPV6_TRANSPARENT - used by tproxy
IPV6_UNICAST_IF - ipv6 version of IP_UNICAST_IF
and socket option values:
IP_PMTUDISC_OMIT - value for IP_MTU_DISCOVER option, new in linux 3.14
IPV6_PMTUDISC_OMIT - same for IPV6_MTU_DISCOVER
IPV6_PMTUDISC_INTERFACE - ipv6 version of IP_PMTUDISC_INTERFACE
IPV6_PREFER_* - flags for IPV6_ADDR_PREFERENCES
not added: ipv6 flow info and flow label related definitions.
(it's unclear if libc should define these and namespace polluting
type name is involved so they are not provided for now)
linux 3.14 introduced sched_getattr and sched_setattr syscalls in
commit d50dde5a10f305253cbc3855307f608f8a3c5f73
and the related SCHED_DEADLINE scheduling policy in
commit aab03e05e8f7e26f51dee792beddcb5cca9215a5
but struct sched_attr "extended scheduling parameters data structure"
is not yet exported to userspace (necessary for using the syscalls)
so related uapi definitions are not added yet.
the main motivation for this change is that, with the previous
definition, it was arguably illegal, in standard C, to initialize both
si_value and si_pid/si_uid with designated initializers, due to the
rule that only one member of a union can have an initializer. whether
or not this affected real-world application code, it affected some
internal code, and clang was producing warnings (and possibly
generating incorrect code).
the new definition uses a more complex hierarchy of structs and unions
to avoid the need to initialize more than one member of a single union
in usage cases that make sense. further work would be needed to
eliminate even the ones with no practical applications.
at the same time, some fixes are made to the exposed names for
nonstandard fields, to match what software using them expects.
some of these may have been from ancient (pre-SUSv2) POSIX versions;
more likely, they were from POSIX drafts or glibc interpretations of
what ancient versions of POSIX should have added (instead they made
they described functionality mandatory and/or dropped it completely).
others are purely glibc-isms, many of them ill-thought-out, like
providing ways to lookup the min/max values of types at runtime
(despite the impossibility of them changing at runtime and the
impossibility of representing ULONG_MAX in a return value of type
long).
since our sysconf implementation does not support or return meaningful
values for any of these, it's harmful to have the macros around;
applications' build scripts may detect and attempt to use them, only
to get -1/EINVAL as a result.
if removing them does break some applications, and it's determined
that the usage was reasonable, some of these could be added back on an
as-needed basis, but they should return actual meaningful values, not
junk like they were returning before.
The mips arch is special in that it uses different RLIMIT_
numbers than other archs, so allow bits/resource.h to override
the default RLIMIT_ numbers (empty on all archs except mips).
Reported by orc.
in a sense this implementation is incomplete since it doesn't provide
the HWCAP_* macros for use with AT_HWCAP, which is perhaps the most
important intended usage case for getauxval. they will be added at a
later time.
the size and alignment of struct hsearch_data are matched to the glibc
definition for binary compatibility. the members of the structure do
not match, which should not be a problem as long as applications
correctly treat the structure as opaque.
unlike the glibc implementation, this version of hcreate_r does not
require the caller to zero-fill the structure before use.
the definition was found to be incorrect at least for powerpc, and
fixing this cleanly requires making the definition arch-specific. this
will allow cleaning up the definition for other archs to make it more
specific, and reversing some of the ugliness (time_t hacks) introduced
with the x32 port.
this first commit simply copies the existing definition to each arch
without any changes. this is intentional, to make it easier to review
changes made on a per-arch basis.
this was problematic because several archs don't define __WORDSIZE. we
could add it, but I would rather phase this macro out in the long
term. in our version of the headers, UINTPTR_MAX is available here, so
just use it instead.
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 5243e5f160 ,
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.
based on patch contributed by Anthony G. Basile (blueness)
some issues remain with the filename generation algorithm and other
small bugs, but this patch has been sitting around long enough that I
feel it's best to get it committed and then work out any remaining
issues.
based on patch by Isaac Dunham, moved to its own file to avoid
increasing bss on static linked programs not using this nonstandard
function but using the standard getgrent function, and vice versa.
the main goal of these changes is to address the case where an
application provides a stack of size N, but TLS has size M that's a
significant portion of the size N (or even larger than N), thus giving
the application less stack space than it expected or no stack at all!
the new strategy pthread_create now uses is to only put TLS on the
application-provided stack if TLS is smaller than 1/8 of the stack
size or 2k, whichever is smaller. this ensures that the application
always has "close enough" to what it requested, and the threshold is
chosen heuristically to make sure "sane" amounts of TLS still end up
in the application-provided stack.
if TLS does not fit the above criteria, pthread_create uses mmap to
obtain space for TLS, but still uses the application-provided stack
for actual call frame stack. this is to avoid wasting memory, and for
the sake of supporting ugly hacks like garbage collection based on
assumptions that the implementation will use the provided stack range.
in order for the above heuristics to ever succeed, the amount of TLS
space wasted on POSIX TSD (pthread_key_create based) needed to be
reduced. otherwise, these changes would preclude any use of
pthread_create without mmap, which would have serious memory usage and
performance costs for applications trying to create huge numbers of
threads using pre-allocated stack space. the new value of
PTHREAD_KEYS_MAX is the minimum allowed by POSIX, 128. this should
still be plenty more than real-world applications need, especially now
that C11/gcc-style TLS is now supported in musl, and most apps and
libraries choose to use that instead of POSIX TSD when available.
at the same time, PTHREAD_STACK_MIN has been decreased. it was
originally set to PAGE_SIZE back when there was no support for TLS or
application-provided stacks, and requests smaller than a whole page
did not make sense. now, there are two good reasons to support
requests smaller than a page: (1) applications could provide
pre-allocated stacks smaller than a page, and (2) with smaller stack
sizes, stack+TLS+TSD can all fit in one page, making it possible for
applications which need huge numbers of threads with minimal stack
needs to allocate exactly one page per thread. the new value of
PTHREAD_STACK_MIN, 2k, is aligned with the minimum size for
sigaltstack.
alternatively, we could define it in sys/socket.h since SO* is
reserved there, and tcp.h includes sys/socket.h in extensions mode.
note that SOL_TCP is simply wrong and it's only here for compatibility
with broken applications. the correct argument to pass for setting TCP
socket options is IPPROTO_TCP, which of course has the same value as
SOL_TCP but works everywhere.
this is a trivial no-op, because dlclose never deletes libraries. thus
we might as well have it in the header in case some application wants
it, since we're already providing it anyway.
based on patch by Pierre Carrier <pierre@gcarrier.fr> that just added
the flag constant, but with minimal additional code so that it
actually works as documented. this is a nonstandard option but some
major software (reportedly, Firefox) uses it and it was easy to add
anyway.
the historical mess of having different definitions for C and C++
comes from the historical C definition as (void *)0 and the fact that
(void *)0 can't be used in C++ because it does not convert to other
pointer types implicitly. however, using plain 0 in C++ exposed bugs
in C++ programs that call variadic functions with NULL as an argument
and (wrongly; this is UB) expect it to arrive as a null pointer. on
64-bit machines, the high bits end up containing junk. glibc dodges
the issue by using a GCC extension __null to define NULL; this is
observably non-conforming because a conforming application could
observe the definition of NULL via stringizing and see that it is
neither an integer constant expression with value zero nor such an
expression cast to void.
switching to 0L eliminates the issue and provides compatibility with
broken applications, since on all musl targets, long and pointers have
the same size, representation, and argument-passing convention. we
could maintain separate C and C++ definitions of NULL (i.e. just use
0L on C++ and use (void *)0 on C) but after careful analysis, it seems
extremely difficult for a C program to even determine whether NULL has
integer or pointer type, much less depend in subtle, unintentional
ways, on whether it does. C89 seems to have no way to make the
distinction. on C99, the fact that (int)(void *)0 is not an integer
constant expression, along with subtle VLA/sizeof semantics, can be
used to make the distinction, but many compilers are non-conforming
and give the wrong result to this test anyway. on C11, _Generic can
trivially make the distinction, but it seems unlikely that code
targetting C11 would be so backwards in caring which definition of
NULL an implementation uses.
as such, the simplest path of using the same definition for NULL in
both C and C++ was chosen. the #undef directive was also removed so
that the compiler can catch and give a warning or error on
redefinition if buggy programs have defined their own versions of
NULL prior to inclusion of standard headers.
