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
Szabolcs Nagy
Kylie McClain
Rich Felker
Khem Raj
Roman Yeryomin
Trutz Behn
Felix Janda
Bobby Bingham