commit d93c0740d8 added use of feature
test macros without including features.h, causing a definition that
should be exposed in the default profile, TSVTX, to appear only when
_XOPEN_SOURCE or higher is explicitly defined.
standing alone, both the signed and int keywords identify the same
type, a (signed) int. however the C language has an exception where,
when the lone keyword int is used to declare a bitfield, it's
implementation-defined whether the bitfield is signed or unsigned. C11
footnote 125 extends this implementation-definedness to typedefs, and
DR#315 extends it to other integer types (for which support with
bitfields is implementation-defined).
while reasonable ABIs (all the ones we support) define bitfields as
signed by default, GCC and compatible compilers offer an option
-funsigned-bitfields to change the default. while any signed types
defined without explicit use of the signed keyword are affected, the
stdint.h types, especially intNN_t, have a natural use in bitfields.
ensure that bitfields defined with these types always have the correct
signedness regardless of compiler & flags used.
see also GCC PR 83294.
this must have been taken from POSIX without realizing that it was
meaningless. the resolution to Austin Group issue #844 removed it from
the standard.
PAGESIZE is actually the version defined in POSIX base, with PAGE_SIZE
being in the XSI option. use PAGESIZE as the underlying definition to
facilitate making exposure of PAGE_SIZE conditional.
add a member of appropriate type to the fpos_t union so that accesses
are well-defined. use long long instead of off_t since off_t is not
always exposed in stdio.h and there's no namespace-clean alias for it.
access is still performed using pointer casts rather than by naming
the union member as a matter of style; to the extent possible, the
naming of fields in opaque types defined in the public headers is not
treated as an API contract with the implementation. access via the
pointer cast is valid as long as the union has a member of matching
type.
based loosely on patch by Hauke Mehrtens; converted to wrap the public
API of the underlying getrandom function rather than direct syscalls,
so that if/when a fallback implementation of getrandom is added it
will automatically get picked up by getentropy too.
NT_ARM_SVE and NT_S390_RI_CB are new in linux commits
43d4da2c45b2f5d62f8a79ff7c6f95089bb24656 and
262832bc5acda76fd8f901d39f4da1121d951222
the rest are older.
musl missed NT_PRFPREG because it followed the glibc api:
https://sourceware.org/bugzilla/show_bug.cgi?id=14890
PR_SVE_SET_VL and PR_SVE_GET_VL controls are new in linux commit
2d2123bc7c7f843aa9db87720de159a049839862
related PR_SVE_* macros were added in
7582e22038a266444eb87bc07c372592ad647439
for synchronous page faults, new in linux commit
1c9725974074a047f6080eecc62c50a8e840d050 and
b6fb293f2497a9841d94f6b57bd2bb2cd222da43
note that only targets that use asm-generic/mman.h have this new
flag defined, so undef it on other targets (mips*, powerpc*).
*_HUGE_SHIFT, *_HUGE_2MB, *_HUGE_1GB are documented in the man page,
so add all of the *_HUGE_* macros from linux uapi.
if MAP_HUGETLB is set, top bits of the mmap flags encode the page size.
see the linux commit aafd4562dfee81a40ba21b5ea3cf5e06664bc7f6
if SHM_HUGETLB is set, top bits of the shmget flags encode the page size.
see the linux commit 4da243ac1cf6aeb30b7c555d56208982d66d6d33
*_HUGE_16GB is defined unsigned to avoid signed left shift ub.
new ethertypes in linux v4.14:
ETH_P_ERSPAN new in 84e54fe0a5eaed696dee4019c396f8396f5a908b
ETH_P_IFE new in 2804fd3af6ba5ae5737705b27146455eabe2e2f8
ETH_P_NSH new in 155e6f649757c902901e599c268f8b575ddac1f8
ETH_P_MAP new in 7373ae7e8f0bf2c0718422481da986db5058b005
MSG_ZEROCOPY socket send flag avoids copy in the kernel
new in linux commit 52267790ef52d7513879238ca9fac22c1733e0e3
SO_ZEROCOPY socket option enables MSG_ZEROCOPY if availale
new in linux commit 76851d1212c11365362525e1e2c0a18c97478e6b
add AF_SMC and PF_SMC for the IBM shared memory communication protocol.
new in linux commit ac7138746e14137a451f8539614cdd349153e0c0
(linux socket.h is not in uapi so this update was missed earlier)
With Linux kernel 4.16 it will be possible to guard more parts of the
Linux header files from a libc. Make use of this in musl to guard all
the structures and other definitions from the Linux header files which
are also defined by the header files provided by musl. This will make
it possible to compile source files which include both the libc
headers and the kernel userspace headers.
This extends the definitions done in commit 04983f2272 ("make
netinet/in.h suppress clashing definitions from kernel headers")
notes added by maintainer:
this function is a GNU extension. it was chosen over the similar BSD
function funopen because the latter depends on fpos_t being an
arithmetic type as part of its public API, conflicting with our
definition of fpos_t and with the intent that it be an opaque type. it
was accepted for inclusion because, despite not being widely used, it
is usually very difficult to extricate software using it from the
dependency on it.
calling pattern for the read and write callbacks is not likely to
match glibc or other implementations, but should work with any
reasonable callbacks. in particular the read function is never called
without at least one byte being needed to satisfy its caller, so that
spurious blocking is not introduced.
contracts for what callbacks called from inside libc/stdio can do are
always complicated, and at some point still need to be specified
explicitly. at the very least, the callbacks must return or block
indefinitely (they cannot perform nonlocal exits) and they should not
make calls to stdio using their own FILE as an argument.
for getting/setting write lifetime hints fcntl commands were
added in linux commit c75b1d9421f80f4143e389d2d50ddfc8a28c8c35
added under _GNU_SOURCE || _BSD_SOURCE, since RWH_* life time
hints are not in the POSIX reserved namespace.
SO_MEMINFO added in linux commit a2d133b1d465016d0d97560b11f54ba0ace56d3e
SO_INCOMING_NAPI_ID added in 6d4339028b350efbf87c61e6d9e113e5373545c9
SO_COOKIE added in 5daab9db7b65df87da26fd8cfa695fb9546a1ddb
min max mtu size definitions mostly for drivers.
new in linux commits a52ad514fdf3b8a57ca4322c92d2d8d5c6182485 and
d894be57ca92c8a8819ab544d550809e8731137b
for tcp timestamp control messages, new in linux commit
1c885808e45601b2b6f68b30ac1d999e10b6f606
and export time measurements via tcp_info, added in linux commit
efd90174167530c67a54273fd5d8369c87f9bd32
since setlocale(cat, NULL) is required to return the setting for the
global locale, there is no standard mechanism to obtain the name of
the currently active thread-local locale set by uselocale. this makes
it impossible for application/library software to load appropriate
translations, etc. unless using the gettext implementation provided by
libc, which has privileged access to libc internals.
to fill this gap, glibc introduced the _NL_LOCALE_NAME macro which can
be used with nl_langinfo to obtain the name. GNU gettext/gnulib code
already use this functionality on glibc, and can easily be adapted to
make use of it on non-glibc systems if it's available; for other
systems they poke at locale implementation internals, which we want to
avoid. this patch provides a compatible interface to the one glibc
introduced.
the bit is reserved anyway for ABI-compat reasons; this documents it
and makes it so we can have posix_spawnattr_setflags check for flag
validity without hard-coding an anonymous bit value.
this has been slated for removal for a long time. there is
fundamentally no way to implement stdarg without compiler assistance;
any attempt to do so has serious undefined behavior; its working
depends not just (as a common misconception goes) on ABI, but also on
assumptions about compiler code generation internal to a translation
unit, which is not subject to external ABI constraints.
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.
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.
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.
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.
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
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.
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.
since cpu sets can be dynamically allocated and have variable size,
accessing their contents via ->__bits is not valid; performing pointer
arithmetic outside the range of the size of the declared __bits array
results in undefined beahavior. instead, only use cpu_set_t for
fixed-size cpu set objects (instantiated by the caller) and as an
abstract pointer type for dynamically allocated ones. perform all
accesses simply by casting the abstract pointer type cpuset_t * back
to unsigned long *.
this reverts commit 2c1f8fd5da. without
the _Noreturn attribute, the compiler cannot use asserts to perform
reachability/range analysis. this leads to missed optimizations and
spurious warnings.
the original backtrace problem that prompted the removal of _Noreturn
was not clearly documented at the time, but it seems to happen only
when libc was built without -g, which also breaks many other
backtracing cases.
modern compilers (for gcc, versions 4.8 and later) automatically
pre-include <stdc-predef.h> to obtain the values of certain predefined
macros specified by ISO C but which reflect properties of the library
implementation, not just the compiler. provide values indicating that
wchar_t is Unicode-encoded and that Annex F (IEEE floating point) is
supported unless the compiler indicates otherwise.
based on patch by Masanori Ogino.
it was changed to EM_OR1K in 200d15479c
as that was meant to be the official name, but glibc and the latest
gabi spec still uses the EM_OPENRISC name:
http://www.sco.com/developers/gabi/latest/ch4.eheader.html
binutils defines both macros so we should do the same for backward
compatibility.
placing the opening brace on the same line as the struct keyword/tag
is the style I prefer and seems to be the prevailing practice in more
recent additions.
these changes were generated by the command:
find include/ arch/*/bits -name '*.h' \
-exec sed -i '/^struct [^;{]*$/{N;s/\n/ /;}' {} +
and subsequently checked by hand to ensure that the regex did not pick
up any false positives.
the kernel ABI value for RUSAGE_CHILDREN is -1, not 1. the latter is
actually interpreted as RUSAGE_THREAD, to obtain values for just the
calling thread and not the whole process.
compilers are free not to copy, or in some cases to clobber, padding
bytes in a structure. while it's an aliasing violation, and thus
undefined behavior, to copy or manipulate other sockaddr types using
sockaddr_storage, it seems likely that traditional code attempts to do
so, and the original intent of the sockaddr_storage structure was
probably to allow such usage.
in the interest of avoiding silent and potentially dangerous breakage,
ensure that there are no actual padding bytes in sockaddr_storage by
moving and adjusting the size of the __ss_padding member so that it
fits exactly.
this change also removes a silent assumption that the alignment of
long is equal to its size.
kernel connection multiplexor macros AF_KCM, PF_KCM, SOL_KCM were
added in linux commit ab7ac4eb9832e32a09f4e8042705484d2fb0aad3
MSG_BATCH sendmsg flag for performance optimization was added
in linux commit f092276d85b82504e8a07498f4e9e0c51f06745c
SOL_* macros are now synced with linux socket.h which is not a uapi
header and glibc did not have the macros either, but that has changed
http://sourceware.org/ml/libc-alpha/2016-05/msg00322.html
new fields and associated linux commit:
tcpi_notsent_bytes, tcpi_min_rtt cd9b266095f422267bddbec88f9098b48ea548fc
tcpi_data_segs_in, tcpi_data_segs_out a44d6eacdaf56f74fad699af7f4925a5f5ac0e7f
new socket option so application can give advice about routing
path quality of connected udp sockets, added in linux commit
a87cb3e48ee86d29868d3f59cfb9ce1a8fa63314
previously, the only way the stopping condition could be met with
correct lengths in the headers invoked undefined behavior, adding
sizeof(struct cmsghdr) beyond the end of the cmsg buffer.
instead, compute and compare sizes rather than pointers.
allows the os to free the marked pages lazily on memory pressure.
expected to increase malloc performance.
new in linux commit 854e9ed09dedf0c19ac8640e91bcc74bc3f9e5c9
new flag for exclusive wakeup mode when an event source fd is attached
to multiple epoll fds but they should not all receive the events.
new in linux commit df0108c5da561c66c333bb46bfe3c1fc65905898
new socket options for setting classic or extended BPF program
for sockets in a SO_REUSEPORT group. added in linux commit
538950a1b7527a0a52ccd9337e3fcd304f027f13
currently five targets use the same mman.h constants and the rest
share most constants too, so move them to sys/mman.h before the
bits/mman.h include where the differences can be corrected by
redefinition of the macros.
this fixes two minor bugs: POSIX_MADV_DONTNEED was wrong on most
targets (it should be the same as MADV_DONTNEED), and sh defined
the x86-only MAP_32BIT mmap flag.
some software simply uses static_assert if the macro is defined, and
this breaks if the compiler does not recognize the _Static_assert
keyword used to define it.
commit 378f8cb522 added these functions
(as stubs) but left them without declarations. this broke some
autoconf based software that detected linkability of the symbols but
didn't check for a declaration.
si_errno and si_code are swapped in mips siginfo_t compared to other
archs and some si_code values are different. This fix is required
for POSIX timers to work.
based on patch by Dmitry Ivanov.
only have code above the bits/signal.h include that is necessary.
(some types are used for the ucontext struct and mips has to
override a few macro definitions)
this way mips bits/signal.h will be able to affect siginfo_t.
they lock faulted pages into memory (useful when a small part of a
large mapped file needs efficient access), new in linux v4.4, commit
b0f205c2a3082dd9081f9a94e50658c5fa906ff1
MLOCK_* is not in the POSIX reserved namespace for sys/mman.h
allows a ptracer process to disable/enable seccomp filters of the
traced process, useful for checkpoint/restore, new in v4.3 commit
13c4a90119d28cfcb6b5bdd820c233b86c2b0237
IP_BIND_ADDRESS_NO_PORT is a SOL_IP socket option to delay src port
allocation until connect in case src ip is set with bind(port=0).
new in linux v4.2, commit 90c337da1524863838658078ec34241f45d8394d
IPPROTO_MPLS protocol number for mpls over ip.
new in linux v4.2, commit 730fc4371333636a00fed32c587fc1e85c5367e2
TCP_CC_INFO is a new socket option to get congestion control info without
netlink (union tcp_cc_info is in linux/inet_diag.h kernel header).
linux commit 6e9250f59ef9efb932c84850cd221f22c2a03c4a
TCP_SAVE_SYN, TCP_SAVED_SYN socket options are for saving and getting the
SYN headers of passive connections in a server application.
linux commit cd8ae85299d54155702a56811b2e035e63064d3d
Add new tcpi_* fields to struct tcp_info implementing RFC4898 counters.
linux commit 2efd055c53c06b7e89c167c98069bab9afce7e59
Programs such as iptables depend on these constants, which can also
be found defined in other libcs.
Since only TCP_* is reserved as part of tcp.h's namespace, we hide
them behind _BSD_SOURCE (and therefore _DEFAULT_SOURCE) to expose
them by default, but keep it standard conforming.
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.