needed for storage drivers with userspace component that may
run in the IO path, see
linux commit 8d19f1c8e1937baf74e1962aae9f90fa3aeab463
prctl: PR_{G,S}ET_IO_FLUSHER to support controlling memory reclaim
The use of TCP_ in udp.h is not known, fortunately udp.h is not
specified by posix so there are no strict namespace rules, added in
linux commit e27cca96cd68fa2c6814c90f9a1cfd36bb68c593
xfrm: add espintcp (RFC 8229)
TCP_NLA_TIMEOUT_REHASH queries timeout-triggered rehash attempts,
tcpm_ifindex limits the scope of TCP_MD5SIG* sockopt to a device.
see
linux commit 32efcc06d2a15fa87585614d12d6c2308cc2d3f3
tcp: export count for rehash attempts
linux commit 6b102db50cdde3ba2f78631ed21222edf3a5fb51
net: Add device index to tcp_md5sig
add IPPROTO_ETHERNET and IPPROTO_MPTCP, see
linux commit 2677625387056136e256c743e3285b4fe3da87bb
seg6: fix SRv6 L2 tunnels to use IANA-assigned protocol number
linux commit faf391c3826cd29feae02078ca2022d2f912f7cc
tcp: Define IPPROTO_MPTCP
putting the (simple) definition in alltypes.h seems like the best
solution here. making sys/ioctl.h implicitly include termios.h is
probably excess namespace pollution.
these have been adopted for future issue of POSIX as the outcome of
Austin Group issue 1151, and are simply functions performing the roles
of the historical ioctls. since struct winsize is being standardized
along with them, its definition is moved to the appropriate header.
there is some chance this will break source files that expect struct
winsize to be defined by sys/ioctl.h without including termios.h. if
this happens, further changes will be needed to have sys/ioctl.h
expose it too.
this is a prerequisite for addition of other interfaces that use
kernel tids, including futex and SIGEV_THREAD_ID.
there is some ambiguity as to whether the semantic return type should
be int or pid_t. either way, futex API imposes a contract that the
values fit in int (excluding some upper reserved bits). glibc used
pid_t, so in the interest of not having gratuitous mismatch (the
underlying types are the same anyway), pid_t is used here as well.
while conceptually this is a syscall, the copy stored in the thread
structure is always valid in all contexts where it's valid to call
libc functions, so it's used to avoid the syscall.
this is added for POSIX-future as the outcome of Austin Group issue
599. since it's in the reserved namespace for pthread.h, there are no
namespace considerations for adding it early.
_POSIX_VDISABLE is only visible if unistd.h has already been included,
so conditional use of it here makes no sense. the value is always 0
anyway; it does not vary.
This enables alternative compilers, which may not define __GNUC__,
to implement alloca, which is still fairly widely used.
This is similar to how stdarg.h already works in musl; compilers must
implement __builtin_va_arg, there is no fallback definition.
this change was discussed on the mailing list thread for the linux
uapi v5.3 patches, and submitted as a v2 patch, but overlooked when I
applied the patches much later.
revert commit f291c09ec9 and apply the
v2 as submitted; the net change is just padding.
notes by Szabolcs Nagy follow:
compared to the linux uapi (and glibc) a padding is used instead of
aligned attribute for keeping the layout the same across targets, this
means the alignment of the struct may be different on some targets
(e.g. m68k where uint64_t is 2 byte aligned) but that should not affect
syscalls and this way the abi does not depend on nonstandard extensions.
allows waiting on a pidfd, in the future it might allow retrieving the
exit status by a non-parent process, see
linux commit 3695eae5fee0605f316fbaad0b9e3de791d7dfaf
pidfd: add P_PIDFD to waitid()
tcpi_rcv_ooopack for tracking connection quality:
linux commit f9af2dbbfe01def62765a58af7fbc488351893c3
tcp: Add TCP_INFO counter for packets received out-of-order
tcpi_snd_wnd peer window size for diagnosing tcp performance problems:
linux commit 8f7baad7f03543451af27f5380fc816b008aa1f2
tcp: Add snd_wnd to TCP_INFO
per thread prctl commands to relax the syscall abi such that top bits
of user pointers are ignored in the kernel. this allows the use of
those bits by hwasan or by mte to color pointers and memory on aarch64:
linux commit 63f0c60379650d82250f22e4cf4137ef3dc4f43d
arm64: Introduce prctl() options to control the tagged user addresses ABI
These were mainly introduced so android can optimize the memory usage
of unused apps.
MADV_COLD hints that the memory range is currently not needed (unlike
with MADV_FREE the content is not garbage, it needs to be swapped):
linux commit 9c276cc65a58faf98be8e56962745ec99ab87636
mm: introduce MADV_COLD
MADV_PAGEOUT hints that the memory range is not needed for a long time
so it can be reclaimed immediately independently of memory pressure
(unlike with MADV_DONTNEED the content is not garbage):
linux commit 1a4e58cce84ee88129d5d49c064bd2852b481357
mm: introduce MADV_PAGEOUT
ptrace API to get details of the syscall the tracee is blocked in, see
linux commit 201766a20e30f982ccfe36bebfad9602c3ff574a
ptrace: add PTRACE_GET_SYSCALL_INFO request
the align attribute was used to keep the layout the same across targets
e.g. on m68k uint32_t is 2 byte aligned, this helps with compat ptrace.
This ensures that the musl definition of 'struct iphdr' does not conflict
with the Linux kernel UAPI definition of it.
Some software, i.e. net-tools, will not compile against 5.4 kernel headers
without this patch and the corresponding Linux kernel patch.
since time64 switchover has changed the size and layout of the struct
anyway, take the opportunity to fix it up so that it can be shared
between 32- and 64-bit ABIs on the same system as long as byte order
matches.
the ut_type member is explicitly padded to make up for m68k having
only 2-byte alignment; explicit padding has no effect on other archs.
ut_session is changed from long to int, with endian-matched padding.
this affects 64-bit archs as well, but brings the type into alignment
with glibc's x86_64 struct, so it should not break software, and does
not break on-disk format. the semantic type is int (pid-like) anyway.
the padding produces correct alignment for the ut_tv member on 32-bit
archs that don't naturally align it, so that ABI matches 64-bit.
this type is presently not used anywhere in the ABI between libc and
libc consumers; it's only used between pairs of consumers if a
third-party utmp library using the system utmpx.h is in use.
the elf_prstatus structure is used in core dumps, and the timeval
structures in it are longs matching the elf class, *not* the kernel
"old timeval" for the arch. this means using timeval here for x32 was
always wrong, despite kernel uapi headers and glibc also exposing it
this way, and of course it's wrong for any arch with 64-bit time_t.
rather than just changing the type on affected archs, use a tagless
struct containing long tv_sec and tv_usec members in place of the
timevals. this intentionally breaks use of them as timevals (e.g.
assignment, passing address, etc.) on 64-bit archs as well so that any
usage unsafe for 32-bit archs is caught even in software that only
gets tested on 64-bit archs. from what I could gather, there is not
any software using these members anyway. the only reason they need to
be fixed to begin with is that the only members which are commonly
used, the saved registers, follow the time members and have the wrong
offset if the time members are sized incorrectly.
commit b60fdf133c broke the
SIOCGSTAMP[NS] ioctl fallbacks introduced in commit
2e554617e5, as well as use of these
ioctls, by creating a situation where bits/ioctl.h could be included
without __LONG_MAX being visible.
linux/input.h and perhaps others use this macro to determine whether
the userspace time_t is 64-bit when potentially defining types in
terms of time_t and derived structures. the name __USE_TIME_BITS64 is
unfortunate; it really should have been in the __UAPI namespace. but
this is what was chosen back in v4.16 when first preparing input.h for
time64 userspace, presumably based on expectations about what the
glibc-internal features.h macro for time64 would be, and changing it
now would just put a new minimum version requirement on kernel
headers.
the __USE_TIME_BITS64 macro is not intended as a public interface. it
is purely an internal contract between libc and Linux uapi headers.
now that all 32-bit archs have 64-bit time_t (and suseconds_t), the
arch-provided _Int64 macro (long or long long, as appropriate) can be
used to define them, and arch-specific definitions are no longer
needed.
now that all 32-bit archs have 64-bit time types, the values for the
time-related socket option macros can be treated as universal for
32-bit archs. the sys/socket.h mechanism for this predates
arch/generic and is instead in the top-level header.
x32, which does not use the new time64 values of the macros, already
has its own overrides, so this commit does not affect it.
these structures can now be defined generically in terms of endianness
and long size. previously, the 32-bit archs all shared a common
definition from the generic bits header, and each 64-bit arch had to
repeat the 64-bit version, with endian conditionals if the arch had
variants of each endianness.
I would prefer getting rid of the preprocessor conditionals for
padding and instead using unnamed bitfield members, like commit
9b2921bea1 did for struct timespec.
however, at present sendmsg, recvmsg, and recvmmsg need access to the
padding members by name to zero them. this could perhaps be cleaned up
in the future.
SO_RCVTIMEO and SO_SNDTIMEO already were, but only in aggregate with
SO_DEBUG and all of the other low/traditional options that varied per
arch. SO_TIMESTAMP* are newly overridable. the two groups have to be
done separately since mips64 and powerpc64 will override the former
but not the latter.
at some point this should be cleaned up to use bits headers more
idiomatically.
if symbols are being redirected to provide the new time64 ABI, dlsym
must perform matching redirections; otherwise, it would poke a hole in
the magic and return pointers to functions that are not safe to call
from a caller using time64 types.
rather than duplicating a table of redirections, use the time64
symbols present in libc's symbol table to derive the decision for
whether a particular symbol needs to be redirected.
the time_t members in struct sched_param are just reserved space to
preserve size and alignment. when time_t changes to 64-bit on 32-bit
archs, this structure should not change.
make definition conditional on _REDIR_TIME64 to match the size of the
old time_t, which can be assumed to be long if _REDIR_TIME64 is
defined.
a _REDIR_TIME64 macro is introduced, which the arch's alltypes.h is
expected to define, to control redirection of symbol names for
interfaces that involve time_t and derived types. this ensures that
object files will only be linked to libc interfaces matching the ABI
whose headers they were compiled against.
along with time32 compat shims, which will be introduced separately,
the redirection also makes it possible for a single libc (static or
shared) to be used with object files produced with either the old
(32-bit time_t) headers or the new ones after 64-bit time_t switchover
takes place. mixing of such object files (or shared libraries) in the
same program will also be possible, but must be done with care; ABI
between libc and a consumer of the libc interfaces is guaranteed to
match by the the symbol name redirection, but pairwise ABI between
consumers of libc that define interfaces between each other in terms
of time_t is not guaranteed to match.
this change adds a dependency on an additional "GNU C" feature to the
public headers for existing 32-bit archs, which is generally
undesirable; however, the feature is one which glibc has depended on
for a long time, and thus which any viable alternative compiler is
going to need to provide. 64-bit archs are not affected, nor will
future 32-bit archs be, regardless of whether they are "new" on the
kernel side (e.g. riscv32) or just newly-added (e.g. a new sparc or
xtensa port). the same applies to newly-added ABIs for existing
machine-level archs.
for time64 support on 32-bit archs, the kernel interfaces use a
timespec layout padded to match the representation of a pair of 64-bit
values, which requires endian-specific padding.
use of an ordinary, non-bitfield, named member for the padding is
undesirable because, on big endian archs, it would alter the
interpretation of traditional (non-designated) initializers of the
form {s,ns}, initializing the padding instead of the tv_nsec member.
unnamed bitfield members solve this problem by not taking part in
initialization, and were the expected solution when the kernel
interfaces were designed. however, they also have further advantages
which we take advantage of here:
positioning of the padding could be controlled by having a
preprocessor conditional with separate definitions of struct timespec
for little and big endian, but whether padding should appear at all is
a function of whether time_t is larger than long. this condition is
not something the preprocessor can determine unless we were to define
a new macro specifically for that purpose.
by using unnamed bitfield members instead of ordinary named members,
we can arrange for the size of the padding to collapse to zero when it
should not be present, just by using sizeof(time_t) and sizeof(long)
in the bitfield width expression, which can be any integer constant
expression.
policy has long been that these definitions are purely a function of
whether long/pointer is 32- or 64-bit, and that they are not allowed
to vary per-arch. move the definition to the shared alltypes.h.in
fragment, using integer constant expressions in terms of sizeof to
vary the array dimensions appropriately. I'm not sure whether this is
more or less ugly than using preprocessor conditionals and two sets of
definitions here, but either way is a lot less ugly than repeating the
same thing for every arch.
LLONG_MAX is uniform for all archs we support and plenty of header and
code level logic assumes it is, so it does not make sense for limits.h
bits mechanism to pretend it's variable.
LONG_BIT can be defined in terms of LONG_MAX; there's no reason to put
it in bits.
by moving LONG_MAX definition to __LONG_MAX in alltypes.h and moving
LLONG_MAX out of bits, there are now no plain-C limits that are
defined in the bits header, so the bits header only needs to be
included in the POSIX or extended profiles. this allows the feature
test macro logic to be removed from the bits header, facilitating a
long-term goal of getting such logic out of bits.
having __LONG_MAX in alltypes.h will allow further generalization of
headers.
archs without a constant PAGESIZE no longer need bits/limits.h at all.
the resolution of Austin Group issue #162 adds endian.h as a standard
header for future versions of the standard, making it no longer
acceptable for some of the functionality to be hidden behind
_BSD_SOURCE or _GNU_SOURCE. the definitions of the [lb]etoh{16,32,64}
function-like macros are kept conditional since they are alternate
names which the standard did not adopt.
building on commit 97d35a552e,
__BYTE_ORDER is now available wherever alltypes.h is included.
endian.h should not be used since, in the future, it will expose
identifiers that are not in the reserved namespace for the headers
which were previously using it.
this change is motivated by the intersection of several factors.
presently, despite being a nonstandard header, endian.h is exposing
the unprefixed byte order macros and functions only if _BSD_SOURCE or
_GNU_SOURCE is defined. this is to accommodate use of endian.h from
other headers, including bits headers, which need to define structure
layout in terms of endianness. with time64 switch-over, even more
headers will need to do this.
at the same time, the resolution of Austin Group issue 162 makes
endian.h a standard header for POSIX-future, requiring that it expose
the unprefixed macros and the functions even in standards-conforming
profiles. changes to meet this new requirement would break existing
internal usage of endian.h by causing it to violate namespace where
it's used.
instead, have the arch's alltypes.h define __BYTE_ORDER, either as a
fixed constant or depending on the right arch-specific predefined
macros for determining endianness. explicit literals 1234 and 4321 are
used instead of __LITTLE_ENDIAN and __BIG_ENDIAN so that there's no
danger of getting the wrong result if a macro is undefined and
implicitly evaluates to 0 at the preprocessor level.
the powerpc (32-bit) bits/endian.h being removed had logic for varying
endianness, but our powerpc arch has never supported that and has
always been big-endian-only. this logic is not carried over to the new
__BYTE_ORDER definition in alltypes.h.
now that commit f7f1079796 removed the
legacy i386 conditional definition, va_list is in no way
arch-specific, and has no reason to be in the future. move it to the
shared part of alltypes.h.in
apply open_tree with OPEN_TREE_CLONE call to the entire subtree, see
linux commit a07b20004793d8926f78d63eb5980559f7813404
vfs: syscall: Add open_tree(2) to reference or clone a mount
see
linux commit a528d35e8bfcc521d7cb70aaf03e1bd296c8493f
statx: Add a system call to make enhanced file info available
these are linux specific and not reserved names for fcntl.h so they
are under _BSD_SOURCE|_GNU_SOURCE.
ethertype for fake VLAN header for DSA, see
linux commit bf5bc3ce8a8f32a0d45b6820ede8f9fc3e9c23df
ether: Add dedicated Ethertype for pseudo-802.1Q DSA tagging
commit 030e526392 added optreset, a BSD
extension to getopt duplicating the functionality (also an extension)
of setting optind to 0, but failed to provide a public declaration for
it. according to the BSD documentation and headers, the application is
not supposed to need to provide its own declaration.
these are presently extensions, thus named with _np to match glibc and
other implementations that provide them; however they are likely to be
standardized in the future without the _np suffix as a result of
Austin Group issue 1208. if so, both names will be kept as aliases.
these members are associated with an unsupported option group. with
time_t changing size on 32-bit archs, all interfaces taking struct
sched_param arguments would need redirection and compat shims in order
to be able to continue offering these members, for no benefit. just
convert them to reserved space instead.
otherwise, 32-bit archs that could otherwise share the generic
bits/ipc.h would need to duplicate the struct ipc_perm definition,
obscuring the fact that it's the same. sysvipc is not widely used and
these headers are not commonly included, so there is no performance
gain to be had by limiting the number of indirectly included files
here.
files with the existing time32 definition of IPC_STAT are added to all
current 32-bit archs now, so that when it's changed the change will
show up as a change rather than addition of a new file where it's less
obvious that the value is changing vs the generic one that was used
before.
to make use of {sem,shm,msg}ctl IPC_STAT functionality to provide
64-bit time_t on 32-bit archs, IPC_STAT and related macros must be
defined with bit 8 (0x100) set. allow archs to define IPC_STAT in
bits/ipc.h, and define the other macros in terms of it so that they
all get the same value of the time64 bit.
to request or change pointer auth keys for criu via ptrace, new in
linux commit d0a060be573bfbf8753a15dca35497db5e968bb0
arm64: add ptrace regsets for ptrauth key management
RFC 4286: "The IPv4 multicast address for All-Snoopers is 224.0.0.106."
from
linux commit 4effd28c1245303dce7fd290c501ac2c11052114
bridge: join all-snoopers multicast address
SO_BINDTOIFINDEX behaves similar to SO_BINDTODEVICE, but takes a
network interface index as argument, rather than the network
interface name. see
linux commit f5dd3d0c9638a9d9a02b5964c4ad636f06cf7e2c
net: introduce SO_BINDTOIFINDEX sockopt
restricts router alert packets received by the socket to the
socket's namespace only. see
linux commit 9036b2fe092a107856edd1a3bad48b83f2b45000
net: ipv6: add socket option IPV6_ROUTER_ALERT_ISOLATE
allows specifying that the speculative store bypass disable bit should
be cleared on exec. see
linux commit 71368af9027f18fe5d1c6f372cfdff7e4bde8b48
x86/speculation: Add PR_SPEC_DISABLE_NOEXEC
needed for android so it can migrate from its ashmem to memfd.
allows making the memfd readonly for future users while keeping
a writable mmap of it. see
linux commit ab3948f58ff841e51feb845720624665ef5b7ef3
mm/memfd: add an F_SEAL_FUTURE_WRITE seal to memfd
includes changes from linux v5.1
linux commit 235328d1fa4251c6dcb32351219bb553a58838d2
fanotify: add support for create/attrib/move/delete events
linux commit 5e469c830fdb5a1ebaa69b375b87f583326fd296
fanotify: copy event fid info to user
linux commit e9e0c8903009477b630e37a8b6364b26a00720da
fanotify: encode file identifier for FAN_REPORT_FID
as well as earlier changes that were missed.
sys/statfs.h is included for fsid_t.
this reverts commit f552c792c7, which
exposed the sysmacros.h macros (device major/minor calculations) for
BSD and GNU profiles to mimic an unintentional glibc behavior some
code depended on. glibc has deprecated and since removed them as the
resolution to bug #19239, so it makes no sense for us to keep this
behavior. affected code should all have been fixed by now, and if it's
not yet fixed it needs to be for use with modern glibc anyway.
Author: Alex Suykov <alex.suykov@gmail.com>
Author: Aric Belsito <lluixhi@gmail.com>
Author: Drew DeVault <sir@cmpwn.com>
Author: Michael Clark <mjc@sifive.com>
Author: Michael Forney <mforney@mforney.org>
Author: Stefan O'Rear <sorear2@gmail.com>
This port has involved the work of many people over several years. I
have tried to ensure that everyone with substantial contributions has
been credited above; if any omissions are found they will be noted
later in an update to the authors/contributors list in the COPYRIGHT
file.
The version committed here comes from the riscv/riscv-musl repo's
commit 3fe7e2c75df78eef42dcdc352a55757729f451e2, with minor changes by
me for issues found during final review:
- a_ll/a_sc atomics are removed (according to the ISA spec, lr/sc
are not safe to use in separate inline asm fragments)
- a_cas[_p] is fixed to be a memory barrier
- the call from the _start assembly into the C part of crt1/ldso is
changed to allow for the possibility that the linker does not place
them nearby each other.
- DTP_OFFSET is defined correctly so that local-dynamic TLS works
- reloc.h LDSO_ARCH logic is simplified and made explicit.
- unused, non-functional crti/n asm files are removed.
- an empty .sdata section is added to crt1 so that the
__global_pointer reference is resolvable.
- indentation style errors in some asm files are fixed.
FP_FAST_FMA can be defined if "the fma function generally executes about
as fast as, or faster than, a multiply and an add of double operands",
which can only be true if the fma call is inlined as an instruction.
gcc sets __FP_FAST_FMA if __builtin_fma is inlined as an instruction,
but that does not mean an fma call will be inlined (e.g. it is defined
with -fno-builtin-fma), other compilers (clang) don't even have such
macro, but this is the closest we can get.
(even if the libc fma implementation is a single instruction, the extern
call overhead is already too big when the macro is used to decide between
x*y+z and fma(x,y,z) so it cannot be based on libc only, defining the
macro unconditionally on targets which have fma in the base isa is also
incorrect: the compiler might not inline fma anyway.)
this solution works with gcc unless fma inlining is explicitly turned off.
POSIX: "[If] either O_TTY_INIT is set in oflag or O_TTY_INIT has the
value zero, open() shall set any non-standard termios structure
terminal parameters to a state that provides conforming behavior."
The Linux kernel tty drivers always perform initialisation on their
devices to set known good termios values during the open(2) call. This
means that setting O_TTY_INIT to zero is conforming.
This parameter was incorrectly declared to be a pointer to a function
accepting zero parameters. The intent of makecontext is that it is
possible to pass integer parameters to the function, so this should
have been a pointer to a function accepting an unspecified set of
parameters.
aarch64 pointer authentication code related prctl that allows
reinitializing the key for the thread, added in linux commit
ba830885656414101b2f8ca88786524d4bb5e8c1
NT_MIPS_MSA for ptrace access to mips simd arch reg set, added in linux
commit 3cd640832894b85b5929d5bda74505452c800421
NT_ARM_PAC_MASK for ptrace access to pointer auth code mask, added in
commit ec6e822d1a22d0eef1d1fa260dff751dba9a4258
C-SKY support was added to binutils 2.32 in commit
b8891f8d622a31306062065813fc278d8a94fe21
the elf.h change was added to glibc 2.29 in commit
4975f0c3d0131fdf697be0b1631c265e5fd39088
NT_MIPS_FP_MODE is new in linux commit
1ae22a0e35636efceab83728ba30b013df761592
NT_MIPS_DSP is new in linux commit
44109c60176ae73924a42a6bef64ef151aba9095
new fields for RFC 4898 tcp stats in linux
tcpi_bytes_sent added in commit ba113c3aa79a7f941ac162d05a3620bdc985c58d
tcpi_bytes_retrans added in commit fb31c9b9f6c85b1bad569ecedbde78d9e37cd87b
tcpi_dsack_dups added in commit 7e10b6554ff2ce7f86d5d3eec3af5db8db482caa
tcpi_reord_seen added in commit 7ec65372ca534217b53fd208500cf7aac223a383
The new fields change the size of a public struct and thus an ABI break,
but this is how the getsockopt TCP_INFO api is designed: the tcp_info
type must only be used with a length parameter in extern interfaces.
inotify_add_watch flag to prevent modifying existing watch descriptors,
when used on an already watched inode it fails with EEXIST.
added in linux commit 4d97f7d53da7dc830dbf416a3d2a6778d267ae68
On s390x, POSIX_FADV_DONTNEED and POSIX_FADV_NOREUSE have different
values than on all other architectures that Linux supports.
Handle this difference by wrapping their definitions in
include/fcntl.h in #ifdef, so that arch/s390x/bits/fcntl.h can
override them.
as noted in Austin Group issue #1236, the XSI shading for TSVTX is
misplaced in the html version of the standard; it was only supposed to
be on the description text. the intent was that the definition always
be visible, which is reflected in the pdf version of the standard.
this reverts commits d93c0740d8 and
729fef0a93.
C11 removed the requirement that FILE be a complete type, which was
deemed erroneous, as part of the changes introduced by N1439 regarding
completeness of types (see footnote 6 for specific mention of FILE).
however the current version of POSIX is still based on C99 and
incorporates the old requirement that FILE be a complete type.
expose an arbitrary, useless complete type definition because the
actual object used to represent FILE streams cannot be public/ABI.
thanks to commit 13d1afa46f, we now have
a framework for suppressing the public complete-type definition of FILE
when stdio.h is included internally, so that a different internal
definition can be provided. this is perfectly well-defined, since the
same struct tag can refer to different types in different translation
units. it would be a problem if the implementation were accessing the
application's FILE objects or vice versa, but either would be
undefined behavior.
the motivation for this change is twofold. first, it gets the fallback
logic out of the dynamic linker, improving code readability and
organization. second, it provides application code that wants to use
the membarrier syscall, which depends on preregistration of intent
before the process becomes multithreaded unless unbounded latency is
acceptable, with a symbol that, when linked, ensures that this
registration happens.
new in linux commit 76b7f670730e87974f71df9f6129811e2769666e
in struct signalfd_siginfo the pad member is changed to __pad to keep
the namespace clean, it's not part of the public api.
add UDP_NO_CHECK6_* to restrict zero UDP6 checksums, new in linux commit
1c19448c9ba6545b80ded18488a64a7f3d8e6998 (pre-v4.18 change, was missed)
add UDP_SEGMENT to support generic segmentation offload for udp datagrams,
bec1f6f697362c5bc635dacd7ac8499d0a10a4e7 (new in v4.18)
add packet delivery info to tcp_info,
new in linux commit feb5f2ec646483fb66f9ad7218b1aad2a93a2a5c
add TCP_ZEROCOPY_RECEIVE socket option for zerocopy receive,
new in linux commit 05255b823a6173525587f29c4e8f1ca33fd7677d
add TCP_INQ socket option and TCP_CM_INQ cmsg to get in-queue bytes in cmsg
upon read, new in linux commit b75eba76d3d72e2374fac999926dafef2997edd2
add TCP_REPAIR_* to fix repair socket window probe patch,
new in linux commit 31048d7aedf31bf0f69c54a662944632f29d82f2
revert commit a603a75a72.
as a result of commit 1c84c99913 this is
now safe, assuming an interpretation of the somewhat-underspecified
attribute((const)) consistent with real-world usage.
previously, a common __posix_spawnx backend was used that accepted an
additional argument for the execve variant to call in the child. this
moderately bloated up the posix_spawn function, shuffling arguments
between stack and/or registers to call a 7-argument function from a
6-argument one.
instead, tuck the exec function pointer in an unused part of the
(large) pthread_spawnattr_t structure, and have posix_spawnp duplicate
the attributes and fill in a pointer to __execvpe. the net code size
change is minimal, but the weight is shifted to the "heavier" function
which already pulls in more dependencies.
as a bonus, we get rid of an external symbol (__posix_spawnx) that had
no really good place for a declaration because it shouldn't have
existed to begin with.
commit 201995f382 introduced a hack
utilizing the signedness of character constants at the preprocessor
level to avoid depending on the gcc-specific __CHAR_UNSIGNED__ predef.
while this trick works on gcc and presumably other compilers being
used, it's not clear that the behavior it depends on is actually
conforming. C11 6.4.4.4 ¶10 defines character constants as having type
int, and 6.10.1 ¶4 defines preprocessor #if arithmetic to take place
in intmax_t or uintmax_t, depending on the signedness of the integer
operand types, and it is specified that "this includes interpreting
character constants".
if character literals had type char and just promoted to int, it would
be clear that when char is unsigned they should behave as uintmax_t at
the preprocessor level. however, as written the text of the standard
seems to require that character constants always behave as intmax_t,
corresponding to int, at the preprocessor level.
since there is a good deal of ambiguity about the correct behavior and
a risk that compilers will disagree or that an interpretation may
mandate a change in the behavior, do not rely on it for defining
CHAR_MIN and CHAR_MAX correctly. instead, use the signedness of the
value (as opposed to the type) of '\xff', which will be positive if
and only if plain char is unsigned. this behavior is clearly
specified, and the specific case '\xff' is even used in an example,
under 6.4.4.4 of the standard.
commit 98c9af5001 wrongly claimed they
do not need to be valid for such usage, but the last sentence of C11
7.1.4 ¶1 imposes a broad requirement that all macros specified as
integer constant expressions also need to be valid for #if.
simply write the value out explicitly. there is no value here in
pretending that the width of int will vary.
