the ':' in optstring has special meaning as a flag applying to the
previous option character, or to getopt's error handling behavior when
it appears at the beginning. don't also accept a "-:" option based on
its presence.
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
HWCAP_SVE is new in linux commit 43994d824e8443263dc98b151e6326bf677be52e
HWCAP_SHA3, HWCAP_SM3, HWCAP_SM4, HWCAP_ASIMDDP and HWCAP_SHA512 are new in
f5e035f8694c3bdddc66ea46ecda965ee6853718
PPC_FEATURE2_HTM_NO_SUSPEND is new in linux commit
cba6ac4869e45cc93ac5497024d1d49576e82666
PPC_FEATURE2_DARN and PPC_FEATURE2_SCV were new in v4.12 in commit
a4700a26107241cc7b9ac8528b2c6714ff99983d
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*).
use the same token to define TIOCSER_TEMT as is used in ioctl.h
so when both headers are included there are no redefinition warnings
during musl build.
*_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)
these additions were made by scanning git log since the last major
update in commit 790580b2fc47bc20e613336cb937a120422a770c. in addition
to git-level commit authorship, "patch by" text in the commit message
was also scanned. this idiom was used in the past for patches that
underwent substantial edits when merging or where the author did not
provide a commit message. going forward, my intent is to use commit
authorship consistently for attribution.
as before my aim was adding everyone with either substantial code
contributions or a pattern of ongoing simple patch submission; any
omissions are unintentional.
Maintainer's note: at one point, -lcompiler_rt apparently worked, and
may still work and be preferable if one has manually installed the
library in a public lib directory. but with current versions of clang,
the full pathname to the library file is needed. the original patch
removed the -lcompiler_rt check; I have left it in place in case there
are users depending on it, and since, when it does work, it's
preferable so as not to code a dependency on the specific compiler
version and paths in config.mak.
this is more extensible if we need to consider additional errors, and
more efficient as long as the compiler does not know it can cache the
result of __errno_location (a surprisingly complex issue detailed in
commit a603a75a72bb469c6be4963ed1b55fabe675fe15).
It's better to make execvp continue PATH search on ENOTDIR rather than
issuing an error. Bogus entries should not render rest of PATH invalid.
Maintainer's note: POSIX seems to require the search to continue like
this as part of XBD 8.3 Other Environment Variables. Only errors that
conclusively determine non-existence are candidates for continuing;
otherwise for consistency we have to report the error.
when a null buffer pointer is passed to fmemopen, requesting it
allocate its own memory buffer, extremely large size arguments near
SIZE_MAX could overflow and result in underallocation. this results
from omission of the size of the cookie structure in the overflow
check but inclusion of it in the calloc call.
instead of accounting for individual small contributions to the total
allocation size needed, simply reject sizes larger than PTRDIFF_MAX,
which will necessarily fail anyway. then adding arbitrary fixed-size
structures is safe without matching up the expressions in the
comparison and the allocation.
Currently getcwd(3) can succeed without returning an absolute path
because the underlying getcwd syscall, starting with linux commit
v2.6.36-rc1~96^2~2, may succeed without returning an absolute path.
This is a conformance issue because "The getcwd() function shall
place an absolute pathname of the current working directory
in the array pointed to by buf, and return buf".
Fix this by checking the path returned by syscall and failing with
ENOENT if the path is not absolute. The error code is chosen for
consistency with the case when the current directory is unlinked.
Similar issue was fixed in glibc recently, see
https://sourceware.org/bugzilla/show_bug.cgi?id=22679
in theory non-absolute origins can only arise when either the main
program is invoked by running ldso as a command (inherently non-suid)
or when dlopen was called with a relative pathname containing at least
one slash. such usage would be inherently insecure in an suid program
anyway, so the old behavior here does not seem to have been insecure.
harden against it anyway.
the rpath fixup code assumed any module's name field would contain at
least one slash, an invariant which is usually met but not in the case
of a main executable loaded from the current working directory by
running ldd or ldso as a command. it would be possible to make this
invariant always hold, but it has a higher runtime allocation cost and
does not seem useful elsewhere, so just patch things up in fixup_rpath
instead.
it's unclear from the specification whether the word "consumes" in
"consumes more than four bytes to represent a year" refers just to
significant places or includes leading zeros due to field width
padding. however the examples in the rationale indicate that the
latter was the intent. in particular, the year 270 is shown being
formatted by %+5Y as +0270 rather than 00270.
previously '+' prefixing was implemented just by comparing the year
against 10000. instead, count the number of significant digits and
padding bytes to be added, and use the total to determine whether to
apply the '+' prefix.
based on testing by Dennis Wölfing.
the code to strip initial sign and leading zeros inadvertently
stripped all the zeros and the subsequent '-' separating the month.
instead, only strip sign characters from the very first position, and
only strip zeros when they are followed by another digit.
based on testing by Dennis Wölfing.
in the original submission of the patch that became commit
7c709f2d4f9872d1b445f760b0e68da89e256b9e, and in subsequent reading of
it by others, it was not clear that the new member had to be inserted
before canary_at_end, or that inserting it at that location was safe.
add comments to document.
Do not retry waitpid if the child was terminated by a signal. Do not
examine status: since we are not passing any flags, we will not receive
stop or continue notifications.
commit f9fb20b42da0e755d93de229a5a737d79a0e8f60 switched from using a
pipe for the result to conveying it via the child process exit status.
Alexander Monakov pointed out that the latter could fail if the
application is not expecting faccessat to produce a child and performs
a wait operation with __WCLONE or __WALL, and that it is not clear
whether it's guaranteed to work when SIGCHLD's disposition has been
set to SIG_IGN.
in addition, that commit introduced a bug that caused EACCES to be
produced instead of EBUSY due to an exit path that was overlooked when
the error channel was changed, and introduced a spurious retry loop
around the wait operation.
the Linux and FreeBSD man pages for dladdr document dli_fbase as the
"base address" of the library/module found. normally (e.g. AT_BASE)
the term "base" is used to denote the base address relative to which
p_vaddr addresses are interpreted; however in the case of dladdr's
Dl_info structure, existing implementations define it as the lowest
address of the mapping, which makes sense in the context of
determining which module's memory range the input address falls
within.
since this is a nonstandard interface provided to mimic one provided
by other implementations, adjust it to match their behavior.
Consider the first equals sign found in the option to be the delimiter
between it and its argument, even if it matches an equals sign in the
option name. This avoids consuming the equals sign, which would prevent
finding the argument. Instead, it forces a partial match of the part of
the option name before the equals sign.
Maintainer's note: GNU getopt_long does not explicitly document this
behavior, but it can be seen as a consequence of how partial matches
are specified, and at least GNU (bfd) ld is known to make use of it.
If we find a partial option name match, we need to keep looking for
ambiguous/conflicting options. However, we need to remember the position
in the candidate argument to find its option-argument later, if there is
one. This fixes e.g. option "foobar" being given as "--fooba=baz".
commit 78897b0dc00b7cd5c29af5e0b7eebf2396d8dce0 wrongly simplified
Dmitry Levin's original submitted patch fixing alt-form octal with the
zero flag and field width present, omitting the special case where the
value is zero. as a result, printf("%#o",0) wrongly prints "00" rather
than "0".
the logic prior to this commit was actually better, in that it was
aligned with how the alt-form flag (#) for printf is specified ("it
shall increase the precision"). at the time there was no good way to
avoid the zero flag issue with the old logic, but commit
167dfe9672c116b315e72e57a55c7769f180dffa added tracking of whether an
explicit precision was provided.
revert commit 78897b0dc00b7cd5c29af5e0b7eebf2396d8dce0 and switch to
using the explicit precision indicator for suppressing the zero flag.
