the sign character produced came from the sign of tm_gmtoff/3600 as an
integer division, which is zero for negative offsets smaller in
magnitude than 3600. instead of printing the hours and minutes as
separate fields, print them as a single value of the form
hours*100+minutes, which naturally has the correct sign.
the specfile for the wrapper was written assuming output is pie only
if -pie appears on the command line. recent (and older patched)
versions of gcc can be configured to produce pie output by default,
adn when used with such a toolchain, the wrapper linked the wrong
startfiles (crt*) containing pic-incompatible code.
rather than trying to figure out gcc's default, simply always use the
pic-compatible start files.
this fixes a major gap in the intended functionality of
pthread_setattr_default_np. if application/library code creating a
thread does not pass a null attribute pointer to pthread_create, but
sets up an attribute object to change other properties while leaving
the stack alone, the created thread will get a stack with size
DEFAULT_STACK_SIZE. this makes pthread_setattr_default_np useless for
working around stack overflow issues in such applications, and leaves
a major risk of regression if previously-working code switches from
using a null attribute pointer to an attribute object.
this change aligns the behavior more closely with the glibc
pthread_setattr_default_np functionality too, albeit via a different
mechanism. glibc encodes "default" specially in the attribute object
and reads the actual default at thread creation time. with this
commit, we now copy the current default into the attribute object at
pthread_attr_init time, so that applications that query the properties
of the attribute object will see the right values.
commit 32482f61da reduced the number of
int members before the dirent buf from 4 to 3, thereby misaligning it
mod sizeof(off_t), producing invalid accesses on any arch where
alignof(off_t)==sizeof(off_t).
rather than re-adding wasted padding, reorder the struct to meet the
requirement and add a comment and static assertion to prevent this
from getting broken again.
previously, this operation succeeded, and the relocation results
worked for access from new threads created after dlopen, but produced
invalid accesses (and possibly clobbered other memory) from threads
that already existed.
the way the check is written, it still permits dlopen of libraries
containing initial-exec references to static TLS (TLS in the main
program or in a dynamic library loaded at startup).
tls_id is one-based, whereas [static_]tls_cnt is a count, so
comparison for checking that a given tls_id is dynamic rather than
static needs to use strict inequality.
this flag is notoriously under-/mis-specified, and in the past it was
implemented as a nop, essentially considering the absence of a
loopback interface with 127.0.0.1 and ::1 addresses an unsupported
configuration. however, common real-world container environments omit
IPv6 support (even for the network-namespaced loopback interface), and
some kernels omit IPv6 support entirely. future systems on the other
hand might omit IPv4 entirely.
treat these as supported configurations and suppress results of the
unconfigured/unsupported address families when AI_ADDRCONFIG is
requested. use routability of the loopback address to make the
determination; unlike other implementations, we do not exclude
loopback from the "an address is configured" condition, since there is
no basis in the specification for such exclusion. obtaining a result
with AI_ADDRCONFIG does not imply routability of the result, and
applications must still be able to cope with unroutable results even
if they pass AI_ADDRCONFIG.
commit 0b80a7b040, which added non-stub
setvbuf, applied the UNGET pushback adjustment to the size of the
buffer passed in, but inadvertently omitted offsetting the start by
the same amount, thereby allowing unget to clobber up to 8 bytes
before the start of the buffer. this bug was introduced in the present
release cycle; no releases are affected.
to produce sorted results roughly corresponding to RFC 3484/6724,
__lookup_name computes routability and choice of source address via
dummy UDP connect operations (which do not produce any packets). since
at the logical level, the properties fed into the sort key are
computed on ipv6 addresses, the code was written to use the v4mapped
ipv6 form of ipv4 addresses and share a common code path for them all.
however, on kernels where ipv6 support has been completely omitted,
this causes ipv4 to appear equally unroutable as ipv6, thereby putting
unreachable ipv6 addresses before ipv4 addresses in the results.
instead, use only ipv4 sockets to compute routability for ipv4
addresses. some gratuitous conversion back and forth is left so that
the logic is not affected by these changes. it may be possible to
simplify the ipv4 case considerably, thereby reducing code size and
complexity.
since slack space at the beginning and/or end of writable load maps is
donated to malloc, the application could obtain valid pointers in
these ranges which dladdr would erroneously identify as part of the
shared object whose mapping they came from.
instead of checking the queried address against the mapping base and
length, check it against the load segments from the program headers,
and only match the dso if it lies within the bounds of one of them.
as a shortcut, if the address does match the range of the mapping but
not any of the load segments, we know it cannot match any other dso
and can immediately return failure.
the early-exit condition for the symbol match loop on exact matches
caused dladdr to produce the first match for an exact match, but the
last match for an inexact match. in the interest of consistency,
require a strictly-closer match to replace an already-found one.
commit 8b8fb7f037 added logic to prevent
matching a symbol with no recorded size (closest-match) when there is
an intervening symbol whose size was recorded, but it only worked when
the intervening symbol was encountered later in the search.
instead of rejecting symbols where addr falls outside their recorded
size during the closest-match search, accept them to find the true
closest-match, then reject such a result only once the search has
finished.
based on patch by Axel Siebenborn, with fixes discussed on the mailing
list after submission and and rebased around the UB fix in commit
e829695fcc.
avoid spurious symbol matches by dladdr beyond symbol size. for
symbols with a size recorded, only match if the queried address lies
within the address range determined by the symbol address and size.
for symbols with no size recorded, the old closest-match behavior is
kept, as long as there is no intervening symbol with a recorded size.
the case where no symbol is matched, but the address does lie within
the memory range of a shared object, is specified as success. fix the
return value and produce a valid (with null dli_sname and dli_saddr)
Dl_info structure.
if a final dot was included in the queried host name to anchor it to
the dns root/suppress search domains, and the result was not a CNAME,
the returned canonical name included the final dot. this was not
consistent with other implementations, confused some applications, and
does not seem desirable.
POSIX specifies returning a pointer to, or to a copy of, the input
nodename, when the canonical name is not available, but does not
attempt to specify what constitutes "not available". in the case of
search, we already have an implementation-defined "availability" of a
canonical name as the fully-qualified name resulting from search, so
defining it similarly in the no-search case seems reasonable in
addition to being consistent with other implementations.
as a bonus, fix the case where more than one trailing dot is included,
since otherwise the changes made here would wrongly cause lookups with
two trailing dots to succeed. previously this case resulted in
malformed dns queries and produced EAI_AGAIN after a timeout. now it
fails immediately with EAI_NONAME.
commit 587f5a53bc moved the definition
of SO_PEERSEC to bits/socket.h for archs where the SO_* macros differ
from their standard values, but failed to add copies of the generic
definition for powerpc and powerpc64.
writable load segments can have size-in-memory larger than their size
in the ELF file, representing bss or equivalent. the initial partial
page has to be zero-filled, and additional anonymous pages have to be
mapped such that accesses don't failt with SIGBUS.
map_library skips redundant MAP_FIXED mapping of the initial
(lowest-address) segment when processing LOAD segments since it was
already mapped when reserving the virtual address range, but in doing
so, inadvertently also skipped the code to fill/map bss. typical
executable and library files have two or more LOAD segments, and the
first one is text/rodata (non-writable) and thus has no bss, but it is
syntactically valid for an ELF program/library to put its writable
segment first, or to have only one segment (everything writable). the
binutils bfd-based linker has been observed to create such programs in
the presence of unusual sections or linker scripts.
fix by moving only the mmap_fixed operation under the conditional
rather than skipping the remainder of the loop body. add a check to
avoid bss processing in the case where the segment is not writable;
this should not happen, but if it does, the change would be a crashing
regression without this check.
the mode member of struct ipc_perm is specified by POSIX to have type
mode_t, which is uniformly defined as unsigned int. however, Linux
defines it with type __kernel_mode_t, and defines __kernel_mode_t as
unsigned short on some archs. since there is a subsequent padding
field, treating it as a 32-bit unsigned int works on little endian
archs, but the order is backwards on big endian archs with the
erroneous definition.
since multiple archs are affected, remedy the situation with fixup
code in the affected functions (shmctl, semctl, and msgctl) rather
than repeating the same shims in syscall_arch.h for every affected
arch.
three ABIs are supported: the default with 68881 80-bit fpu format and
results returned in floating point registers, softfloat-only with the
same format, and coldfire fpu with IEEE single/double only. only the
first is tested at all, and only under qemu which has fpu emulation
bugs.
basic functionality smoke tests have been performed for the most
common arch-specific breakage via libc-test and qemu user-level
emulation. some sysvipc failures remain, but are shared with other big
endian archs and will be fixed separately.
since x86 and m68k are the only archs with 80-bit long double and each
has mandatory endianness, select the variant via endianness.
differences are minor: apparently just byte order and representation
of infinities. the m68k format is not well-documented anywhere I could
find, so if other differences are found they may require additional
changes later.
since this iconv implementation's output is stateless, it's necessary
to know before writing anything to the output buffer whether the
conversion of the current input character will fit.
previously we used a hard-coded table of the output size needed for
each supported output encoding, but failed to update the table when
adding support for conversion to jis-based encodings and again when
adding separate encoding identifiers for implicit-endianness utf-16/32
and ucs-2/4 variants, resulting in out-of-bound table reads and
incorrect size checks. no buffer overflow was possible, but the
affected characters could be converted incorrectly, and iconv could
potentially produce an incorrect return value as a result.
remove the hard-coded table, and instead perform the recursive iconv
conversion to a temporary buffer, measuring the output size and
transferring it to the actual output buffer only if the whole
converted result fits.
this case is handled with a recursive call to iconv using a
specially-constructed conversion descriptor. the constant 0 was used
as the offset for utf-8, since utf-8 appears first in the charmaps
table, but the offset used needs to point into the charmap entry, past
the name/aliases at the beginning, to the byte identifying the
encoding. as a result of this error, junk was produced.
instead, call find_charmap so we don't have to hard-code a nontrivial
offset. with this change, the code has been tested and found to work
in the case of converting the affected hkscs characters to utf-8.
the wrapper start function that performs scheduling operations is
unreachable if pthread_attr_setinheritsched is never called, so move
it there rather than the pthread_create source file, saving some code
size for static-linked programs.
eliminate the awkward startlock mechanism and corresponding fields of
the pthread structure that were only used at startup.
instead of having pthread_create perform the scheduling operations and
having the new thread wait for them to be completed, start the new
thread with a wrapper start function that performs its own scheduling,
sending the result code back via a futex. this way the new thread can
use storage from the calling thread's stack rather than permanent
fields in the pthread structure.
over time the pthread structure has accumulated a lot of cruft taking
up size. this commit removes unused fields and packs booleans and
other small data more efficiently. changes which would also require
changing code are not included at this time.
non-volatile booleans are packed as unsigned char bitfield members.
the canceldisable and cancelasync fields need volatile qualification
due to how they're accessed from the cancellation signal handler and
cancellable syscalls called from signal handlers. since volatile
bitfield semantics are not clearly defined, discrete char objects are
used instead.
the pid field is completely removed; it has been unused since commit
83dc6eb087.
the tid field's type is changed to int because its use is as a value
in futexes, which are defined as plain int. it has no conceptual
relationship to pid_t. also, its position is not ABI.
startlock is reduced to a length-1 array. the second element was
presumably intended as a waiter count, but it was never used and made
no sense, since there is at most one waiter.
previously, some accesses to the detached state (from pthread_join and
pthread_getattr_np) were unsynchronized; they were harmless in
programs with well-defined behavior, but ugly. other accesses (in
pthread_exit and pthread_detach) were synchronized by a poorly named
"exitlock", with an ad-hoc trylock operation on it open-coded in
pthread_detach, whose only purpose was establishing protocol for which
thread is responsible for deallocation of detached-thread resources.
instead, use an atomic detach_state and unify it with the futex used
to wait for thread exit. this eliminates 2 members from the pthread
structure, gets rid of the hackish lock usage, and makes rigorous the
trap added in commit 80bf595255 for
catching attempts to join detached threads. it should also make
attempt to detach an already-detached thread reliably trap.
if the last thread exited via pthread_exit, the logic that marked it
dead did not account for the possibility of it targeting itself via
atexit handlers. for example, an atexit handler calling
pthread_kill(pthread_self(), SIGKILL) would return success
(previously, ESRCH) rather than causing termination via the signal.
move the release of killlock after the determination is made whether
the exiting thread is the last thread. in the case where it's not,
move the release all the way to the end of the function. this way we
can clear the tid rather than spending storage on a dedicated
dead-flag. clearing the tid is also preferable in that it hardens
against inadvertent use of the value after the thread has terminated
but before it is joined.
posix documents in the rationale and future directions for
pthread_kill that, since the lifetime of the thread id for a joinable
thread lasts until it is joined, ESRCH is not a correct error for
pthread_kill to produce when the target thread has exited but not yet
been joined, and that conforming applications cannot attempt to detect
this state. future versions of the standard may explicitly require
that ESRCH not be returned for this case.
the tid field in the pthread structure is not volatile, and really
shouldn't be, so as not to limit the compiler's ability to reorder,
merge, or split loads in code paths that may be relevant to
performance (like controlling lock ownership).
however, use of objects which are not volatile or atomic with futex
wait is inherently broken, since the compiler is free to transform a
single load into multiple loads, thereby using a different value for
the controlling expression of the loop and the value passed to the
futex syscall, leading the syscall to block instead of returning.
reportedly glibc's pthread_join was actually affected by an equivalent
issue in glibc on s390.
add a separate, dedicated join_futex object for pthread_join to use.
the static const zero set ended up getting put in bss instead of
rodata, wasting writable memory, and the call to memcmp was
size-inefficient. generally for nonstandard extension functions we try
to avoid poking at any internals directly, but the way the zero set
was setup was arguably already doing so.
to support the GNU extension of allocating a buffer for getcwd's
result when a null pointer is passed without incurring a link
dependency on free, we use a PATH_MAX-sized buffer on the stack and
only duplicate it to allocated storage after the operation succeeds.
unfortunately this imposed excessive stack usage on all callers,
including those not making use of the GNU extension.
instead, use a VLA to make stack allocation conditional.
in thumb mode, r7 is the ABI frame pointer register, and unless frame
pointer is disabled, gcc insists on treating it as a fixed register,
refusing to spill it to satisfy constraints. unfortunately, r7 is also
used in the syscall ABI for passing the syscall number.
up til now we just treated this as a requirement to disable frame
pointer when generating code as thumb, but it turns out gcc forcibly
enables frame pointer, and the fixed register constraint that goes
with it, for functions which contain VLAs. this produces an
unacceptable arch-specific constraint that (non-arm-specific) source
files making syscalls cannot use VLAs.
as a workaround, avoid r7 register constraints when producing thumb
code and instead save/restore r7 in a temp register as part of the asm
block. at some point we may want/need to support armv6-m/thumb1, so
the asm has been tweaked to be thumb1-compatible while also
near-optimal for thumb2: it allows the temp and/or syscall number to
be in high registers (necessary since r0-r5 may all be used for
syscalll args) and in thumb2 mode allows the syscall number to be an
8-bit immediate.
for getopt_long, partial (prefix) matches of long options always begin
with "--" and thus can never be ambiguous with a short option. for
getopt_long_only, though, a single-character option can match both a
short option and as a prefix for a long option. in this case, we
wrongly interpreted it as a prefix for the long option.
introduce a new pass, only in long-only mode, to check the prefix
match against short options before accepting it. the only reason
there's a slightly nontrivial loop being introduced rather than strchr
is that our getopt already supports multibyte short options, and
getopt_long_long should handle them consistently. a temp buffer and
strstr could have been used, but the code to set it up would be just
as large as what's introduced here and it would unnecessarily pull in
relatively large code for strstr.
commit 618b18c78e removed the previous
detection and hardening since it was incorrect. commit
72141795d4 already handled all that
remained for hardening the static-linked case. in the dynamic-linked
case, have the dynamic linker check whether malloc was replaced and
make that information available.
with these changes, the properties documented in commit
c9f415d7ea are restored: if calloc is
not provided, it will behave as malloc+memset, and any of the
memalign-family functions not provided will fail with ENOMEM.
this change serves multiple purposes:
1. it ensures that static linking of memalign-family functions will
pull in the system malloc implementation, thereby causing link errors
if an attempt is made to link the system memalign functions with a
replacement malloc (incomplete allocator replacement).
2. it eliminates calls to free that are unpaired with allocations,
which are confusing when setting breakpoints or tracing execution.
as a bonus, making __bin_chunk external may discourage aggressive and
unnecessary inlining of it.
the generated code should be mostly unchanged, except for explicit use
of C_INUSE in place of copying the low bits from existing chunk
headers/footers.
these changes also remove mild UB due to dubious arithmetic on
pointers into imaginary size_t[] arrays.
commit c9f415d7ea included checks to
make calloc fallback to memset if used with a replaced malloc that
didn't also replace calloc, and the memalign family fail if free has
been replaced. however, the checks gave false positives for
replacement whenever malloc or free resolved to a PLT entry in the
main program.
for now, disable the checks so as not to leave libc in a broken state.
this means that the properties documented in the above commit are no
longer satisfied; failure to replace calloc and the memalign family
along with malloc is unsafe if they are ever called.
the calloc checks were correct but useless for static linking. in both
cases (simple or full malloc), calloc and malloc are in a source file
together, so replacement of one but not the other would give linking
errors. the memalign-family check was useful for static linking, but
broken for dynamic as described above, and can be replaced with a
better link-time check.
replacement is subject to conditions on the replacement functions.
they may only call functions which are async-signal-safe, as specified
either by POSIX or as an implementation-defined extension. if any
allocator functions are replaced, at least malloc, realloc, and free
must be provided. if calloc is not provided, it will behave as
malloc+memset. any of the memalign-family functions not provided will
fail with ENOMEM.
in order to implement the above properties, calloc and __memalign
check that they are using their own malloc or free, respectively.
choice to check malloc or free is based on considerations of
supporting __simple_malloc. in order to make this work, calloc is
split into separate versions for __simple_malloc and full malloc;
commit ba819787ee already did most of
the split anyway, and completing it saves an extra call frame.
previously, use of -Bsymbolic-functions made dynamic interposition
impossible. now, we are using an explicit dynamic-list, so add
allocator functions to the list. most are not referenced anyway, but
all are added for completeness.
instead of using a waiters count, add a bit to the lock field
indicating that the lock may have waiters. threads which obtain the
lock after contending for it will perform a potentially-spurious wake
when they release the lock.
the existing laddr function for fdpic cannot translate ELF virtual
addresses outside of the LOAD segments to runtime addresses because
the fdpic loadmap only covers the logically-mapped part. however the
whole point of reclaim_gaps is to recover the slack space up to the
page boundaries, so it needs to work with such addresses.
add a new laddr_pg function that accepts any address in the page range
for the LOAD segment by expanding the loadmap records out to page
boundaries. only use the new version for reclaim_gaps, so as not to
impact performance of other address lookups.
also, only use laddr_pg for the start address of a gap; the end
address lies one byte beyond the end, potentially in a different page
where it would get mapped differently. instead of mapping end, apply
the length (end-start) to the mapped value of start.
we have always bound symbols at libc.so link time rather than runtime
to minimize startup-time relocations and overhead of calls through the
PLT, and possibly also to preclude interposition that would not work
correctly anyway if allowed. historically, binding at link-time was
also necessary for the dynamic linker to work, but the dynamic linker
bootstrap overhaul in commit f3ddd17380
made it unnecessary.
our use of -Bsymbolic-functions, rather than -Bsymbolic, was chosen
because the latter is incompatible with public global data; it makes
it incompatible with copy relocations in the main program. however,
not all global data needs to be public. by using --dynamic-list
instead with an explicit list, we can reduce the number of symbolic
relocations left for runtime.
this change will also allow us to permit interposition of specific
functions (e.g. the allocator) if/when we want to, by adding them to
the dynamic list.
the Linux SYS_nice syscall is unusable because it does not return the
newly set priority. always use SYS_setpriority. also avoid overflows
in addition of inc by handling large inc values directly without
examining the old nice value.
the catan implementation from OpenBSD includes a FIXME-annotated
"overflow" branch that produces a meaningless and incorrect
large-magnitude result. it was reachable via three paths,
corresponding to gotos removed by this commit, in order:
1. pure imaginary argument with imaginary component greater than 1 in
magnitude. this case does not seem at all exceptional and is
handled (at least with the quality currently expected from our
complex math functions) by the existing non-exceptional code path.
2. arguments on the unit circle, including the pure-real argument 1.0.
these are not exceptional except for ±i, which should produce
results with infinite imaginary component and which lead to
computation of atan2(±0,0) in the existing non-exceptional code
path. such calls to atan2() however are well-defined by POSIX.
3. the specific argument +i. this route should be unreachable due to
the above (2), but subtle rounding effects might have made it
possible in rare cases. continuing on the non-exceptional code path
in this case would lead to computing the (real) log of an infinite
argument, then producing a NAN when multiplying it by I.
for now, remove the exceptional code paths entirely. replace the
multiplication by I with construction of a complex number using the
CMPLX macro so that the NAN issue (3) prevented cannot arise.
with these changes, catan should give reasonably correct results for
real arguments, and should no longer give completely-wrong results for
pure-imaginary arguments outside the interval (-i,+i).
the factor of -i noted in the comment at the top of casin.c was
omitted from the actual code, yielding a result rotated 90 degrees and
propagating into errors in other functions defined in terms of casin.
implement multiplication by -i as a rotation of the real and imaginary
parts of the result, rather than by actual multiplication, since the
latter cannot be optimized without knowledge that the operand is
finite. here, the rotation is the actual intent, anyway.
it was reported by Erik Bosman that poll fails without setting revents
when the nfds argument exceeds the current value for RLIMIT_NOFILE,
causing the subsequent open calls to be bypassed. if the rlimit is
either 1 or 2, this leaves fd 0 and 1 potentially closed but openable
when the application code is reached.
based on a brief reading of the poll syscall documentation and code,
it may be possible for poll to fail under other attacker-controlled
conditions as well. if it turns out these are reasonable conditions
that may happen in the real world, we may have to go back and
implement fallbacks to probe each fd individually if poll fails, but
for now, keep things simple and treat all poll failures as fatal.
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.
previously, MEMOPS_SRCS failed to include arch-specific replacement
files for memcpy, etc., omitting CFLAGS_MEMOPS and thereby potentially
causing build failure if an arch provided C (rather than asm)
replacements for these files.
instead of trying to explicitly include all the files that might have
arch replacements, which is prone to human error, extract final names
to be used out of $(LIBC_OBJS), where the rules for arch replacements
have already been applied. do the same for NOSSP_OBJS, using CRT_OBJS
and LDSO_OBJS rather than repeating ourselves with $(wildcard...) and
explicit pathnames again.
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.
the output delay features (NL*, CR*, TAB*, BS*, and VT*) are
XSI-shaded. VT* is in the V* namespace reservation but the rest need
to be suppressed in base POSIX namespace.
unfortunately this change introduces feature test macro checks into
another bits header. at some point these checks should be simplified
by having features.h handle the "FTM X implies Y" relationships.
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.
use of MB_CUR_MAX encoded a hidden dependency on the currently active
locale for the calling thread, whereas nl_langinfo_l is supposed to
report for the locale passed as an argument.
general policy is that all source files defining a public API or an
ABI mechanism referenced by a public header should include the public
header that declares the interface, so that the compiler or analysis
tools can check the consistency of the declarations. Alexander Monakov
pointed out a number of violations of this principle a few years back.
fix them now.
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.
previously this macro used an odd if/else form instead of the more
idiomatic do/while(0), making it unsafe against omission of trailing
semicolon. the omission would make the following statement conditional
instead of producing an error.
formally, calling readv with a zero-length first iov component should
behave identically to calling read on just the second component, but
presence of a zero-length iov component has triggered bugs in some
kernels and performs significantly worse than a simple read on some
file types.
the stdio FILE read backend's return type is size_t, not ssize_t, and
all of the special (non-fd-backed) FILE types already return the
number of bytes read (zero) on error or eof. only __stdio_read leaked
a syscall error return into its return value.
fread had a workaround for this behavior going all the way back to the
original check-in. remove the workaround since it's no longer needed.
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.
these additions were made by scanning git log since the last major
update in commit 790580b2fc. 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.
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 a603a75a72).
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.
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
7c709f2d4f, 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.
commit f9fb20b42d 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.
commit 78897b0dc0 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
167dfe9672 added tracking of whether an
explicit precision was provided.
revert commit 78897b0dc0 and switch to
using the explicit precision indicator for suppressing the zero flag.
previously, the charset names without endianness specified were always
interpreted as big endian. unicode specifies that UTF-16 and UTF-32
have BOM-determined endianness if BOM is present, and are otherwise
big endian. since commit 5b546faa67
added support for stateful encodings, it is now possible to implement
BOM support via the conversion descriptor state.
for conversions to these charsets, the output is always big endian and
does not have a BOM.
the mapping tables and code are not automatically generated; they were
produced by comparing the output of towupper/towlower against the
mappings in the UCD, ignoring characters that were previously excluded
from case mappings or from alphabetic status (micro sign and circled
letters), and adding table entries or code for everything else
missing.
based very loosely on a patch by Reini Urban.
Rich Felker