commit 31fb174dd2 used
DEFAULT_GUARD_SIZE from pthread_impl.h in a static initializer,
breaking build on archs where its definition, PAGE_SIZE, is not a
constant. instead, just define DEFAULT_GUARD_SIZE as 4096, the minimal
page size on any arch we support. pthread_create rounds up to whole
pages anyway, so defining it to 1 would also work, but a moderately
meaningful value is nicer to programs that use
pthread_attr_getguardsize on default-initialized attribute objects.
based on patch by Timo Teräs:
While generally this is a bad API, it is the only existing API to
affect c++ (std::thread) and c11 (thrd_create) thread stack size.
This patch allows applications only to increate stack and guard
page sizes.
commit 33ce920857 broke pthread_create
in the case where a null attribute pointer is passed; rather than
using the default sizes, sizes of 0 (plus the remainder of one page
after TLS/TCB use) were used.
previously, the pthread_attr_t object was always initialized all-zero,
and stack/guard size were represented as differences versus their
defaults. this required lots of confusing offset arithmetic everywhere
they were used. instead, have pthread_attr_init fill in the default
values, and work with absolute sizes everywhere.
the swprintf write callback never reset its buffer pointers, so after
its 256-byte buffer filled up, it would keep repeating those bytes
over and over in the output until the destination buffer filled up. it
also failed to set the error indicator for the stream on EILSEQ,
potentially allowing output to continue after the error.
the overflow check for years+100 did not account for the extra
year computed from the remaining months. instead, perform this
check after obtaining the final number of years.
the old snprintf design setup the FILE buffer pointers to point
directly into the destination buffer; if n was actually larger than
the buffer size, the pointer arithmetic to compute the buffer end
pointer was undefined. this affected sprintf, which is implemented in
terms of snprintf, as well as some unusual but valid direct uses of
snprintf.
instead, setup the FILE as unbuffered and have its write function
memcpy to the destination. the printf core sets up its own temporary
buffer for unbuffered streams.
the _CS_V6_ENV and _CS_V7_ENV constants are required to be available for use
with confstr. glibc defines these constants with values 1148 and 1149,
respectively.
the only missing (and required) confstr constants are
_CS_POSIX_V7_THREADS_CFLAGS and _CS_POSIX_V7_THREADS_LDFLAGS which remain
unavailable in glibc.
commit 6ffdc4579f set lnz in the code
path for non-zero digits after a huge string of zeros, but the
assignment of dc to lnz truncates if the value of dc does not fit in
int; this is possible for some pathologically long inputs, either via
strings on 64-bit systems or via scanf-family functions.
instead, simply set lnz to match the point at which we add the
artificial trailing 1 bit to simulate nonzero digits after a huge
run of zeros.
the mid-sized integer optimization relies on lnz set up properly
to mark the last non-zero decimal digit, but this was not done
if the non-zero digit lied outside the KMAX digits of the base
10^9 number representation.
so if the fractional part was a very long list of zeros (>2048*9 on
x86) followed by non-zero digits then the integer optimization could
kick in discarding the tiny non-zero fraction which can mean wrong
result on non-nearest rounding mode.
strtof, strtod and strtold were all affected.
in certain cases excessive trailing zeros could cause incorrect
rounding from long double to double or float in decfloat.
e.g. in strtof("9444733528689243848704.000000", 0) the argument
is 0x1.000001p+73, exactly halfway between two representible floats,
this incorrectly got rounded to 0x1.000002p+73 instead of 0x1p+73,
but with less trailing 0 the rounding was fine.
the fix makes sure that the z index always points one past the last
non-zero digit in the base 10^9 representation, this way trailing
zeros don't affect the rounding logic.
in nearest rounding mode exact halfway cases were not following the
round to even rule if the rounding happened at a base 1000000000 digit
boundary of the internal representation and the previous digit was odd.
e.g. printf("%.0f", 1.5) printed 1 instead of 2.
posix requires that EINVAL be returned if the first parameter specifies
the cpu-time clock of the calling thread (CLOCK_THREAD_CPUTIME_ID).
linux returns ENOTSUP instead so we handle this.
j is int32_t and thus j<<31 is undefined if j==1, so j is changed to
uint32_t locally as a quick fix, the generated code is not affected.
(this is a strict conformance fix, future c standard may allow 1<<31,
see DR 463. the bug was inherited from freebsd fdlibm, the proper fix
is to use uint32_t for all bit hacks, but that requires more intrusive
changes.)
reported by Daniel Sabogal
overlayfs may have fairly long lines so we use getline to allocate a
buffer dynamically. The buffer will be allocated on first use, expand as
needed, but will never be free'ed.
Downstream bug: http://bugs.alpinelinux.org/issues/5703
Signed-off-by: Natanael Copa <ncopa@alpinelinux.org>
this patch fixes a large number of missed internal signed-overflow
checks and errors in determining when the return value (output length)
would exceed INT_MAX, which should result in EOVERFLOW. some of the
issues fixed were reported by Alexander Cherepanov; others were found
in subsequent review of the code.
aside from the signed overflows being undefined behavior, the
following specific bugs were found to exist in practice:
- overflows computing length of floating point formats with huge
explicit precisions, integer formats with prefix characters and huge
explicit precisions, or string arguments or format strings longer
than INT_MAX, resulted in wrong return value and wrong %n results.
- literal width and precision values outside the range of int were
misinterpreted, yielding wrong behavior in at least one well-defined
case: string formats with precision greater than INT_MAX were
sometimes truncated.
- in cases where EOVERFLOW is produced, incorrect values could be
written for %n specifiers past the point of exceeding INT_MAX.
in addition to fixing these bugs, we now stop producing output
immediately when output length would exceed INT_MAX, rather than
continuing and returning an error only at the end.
if the requested precision is close to INT_MAX, adding
LDBL_MANT_DIG/3+8 overflows. in practice the resulting undefined
behavior manifests as a large negative result, which is then used to
compute the new end pointer (z) with a wildly out-of-bounds value
(more overflow, more undefined behavior). the end result is at least
incorrect output and character count (return value); worse things do
not seem to happen, but detailed analysis has not been done.
this patch fixes the overflow by performing the intermediate
computation as unsigned; after division by 9, the final result
necessarily fits in int.
we inherited from TRE regexec code that's utterly wrong with respect
to the integer types it's using. while it doesn't appear that
compilers are producing unsafe output, signed integer overflows seem
to happen, and regexec fails to find matches past offset INT_MAX.
this patch fixes the type of all variables/fields used to store
offsets in the string from int to regoff_t. after the changes, basic
testing showed that regexec can now find matches past 2GB (INT_MAX)
and past 4GB on x86_64, and code generation is unchanged on i386.
most of the possible overflows were already ruled out in practice by
regcomp having already succeeded performing larger allocations.
however at least the num_states*num_tags multiplication can clearly
overflow in practice. for safety, check them all, and use the proper
type, size_t, rather than int.
also improve comments, use calloc in place of malloc+memset, and
remove bogus casts.
this is a clone of the fix to the gethostby*_r functions in
commit fe82bb9b92. the man pages
document that the getservby*_r functions set this pointer to
NULL if there was an error or if no record was found.
previously, fflush_unlocked was an alias for an internal backend that
was called by fflush, either for its argument or in a loop for each
file if a null pointer was passed. since the logic for the latter was
in the main fflush function, fflush_unlocked crashed when passed a
null pointer, rather than flushing all open files. since
fflush_unlocked is not a standard function and has no specification,
it's not clear whether it should be expected to accept null pointers
like fflush does, but a reasonable argument could be made that it
should.
this patch eliminates the helper function, simplifying fflush, and
makes fflush_unlocked an alias for fflush, which is valid because the
two functions agree in their behavior in all cases where their
behavior is defined (the unlocked version has undefined behavior if
another thread could hold locks).
commit b91cdbe2bc, in fixing another
issue, changed the logic for how alt-form octal adds the leading zero
to adjust the precision rather than using a prefix character. this
wrongly suppressed the zero flag by mimicing an explicit precision
given by the format string. switch back to using a prefix character.
based on bug report and patch by Dmitry V. Levin, but simplified.
this reverts commit 2c1f8fd5da. without
the _Noreturn attribute, the compiler cannot use asserts to perform
reachability/range analysis. this leads to missed optimizations and
spurious warnings.
the original backtrace problem that prompted the removal of _Noreturn
was not clearly documented at the time, but it seems to happen only
when libc was built without -g, which also breaks many other
backtracing cases.
there was a copy paste error that could cause large ulp errors
in atan2l, atanl, asinl and acosl on aarch64, mips64 and mipsn32.
(the implementation is from freebsd fdlibm, but the tail end
of the polynomial was wrong. 128 bit long double functions
are not yet tested so this went undetected.)
linux containers use separate mount namespace so the /proc
symlink might not point to the right device if the fd was
opened in the parent namespace, in this case return ENOENT.
despite sh not generally using register-pair alignment for 64-bit
syscall arguments, there are arch-specific versions of the syscall
entry points for pread and pwrite which include a dummy argument for
alignment before the 64-bit offset argument.
this code was already under #if 0, but could be confusing if a reader
didn't notice that, and it's almost surely full of bugs and/or
inconsistencies with the current code that uses the gethostbyname2_r
backend.
these changes still do not yield a fully-conforming abort, but they
fix two known issues:
- per POSIX, termination via SIGKILL is not "abnormal", but both ISO C
and POSIX require abort to yield abnormal termination.
- raising SIGKILL fails to do anything to pid 1 in some containers.
now, the trapping instruction produced by a_crash() is expected to
produce abnormal termination, without the risk of invoking a signal
handler since SIGILL and SIGSEGV are blocked, and _Exit, which
contains an infinite loop analogous to the one being removed from
abort itself, is used as a last resort.
this implementation still fails to produce an exit status as if the
process terminated via SIGABRT in cases where SIGABRT is blocked or
ignored, but fixing that is not easy; the obvious pseudo-solutions all
have subtle race conditions where a concurrent fork or exec can expose
incorrect signal state.
commit 6d38c9cf80 provided an
arm-specific version of posix_fadvise to address the alternate
argument order the kernel expects on arm, but neglected to address
that powerpc (32-bit) has the same issue. instead of having arch
variant files in duplicate, simply put the alternate version in the
top-level file under the control of a macro defined in syscall_arch.h.
when commit 0b6eb2dfb2 added the
parentheses around __syscall to invoke the function directly, there
was no __syscall7 in the syscall macro infrastructure, so this hack
was needed. commit 9a3bbce447 fixed that
but failed to remove the hack.
Linux's documentation (robust-futex-ABI.txt) claims that, when a
process dies with a futex on the robust list, bit 30 (0x40000000) is
set to indicate the status. however, what actually happens is that
bits 0-30 are replaced with the value 0x40000000, i.e. bits 0-29
(containing the old owner tid) are cleared at the same time bit 30 is
set.
our userspace-side code for robust mutexes was written based on that
documentation, assuming that kernel would never produce a futex value
of 0x40000000, since the low (owner) bits would always be non-zero.
commit d338b506e3 introduced this
assumption explicitly while fixing another bug in how non-recoverable
status for robust mutexes was tracked. presumably the tests conducted
at that time only checked non-process-shared robust mutexes, which are
handled in pthread_exit (which implemented the documented kernel
protocol, not the actual one) rather than by the kernel.
change pthread_exit robust list processing to match the kernel
behavior, clearing bits 0-29 while setting bit 30, and use the value
0x7fffffff instead of 0x40000000 to encode non-recoverable status. the
choice of value here is arbitrary; any value with at least one of bits
0-29 set should work just as well,
despite clarifications made to the COPYRIGHT file in commit
f0a6139933, there continues to be
confusion about whether the permissions granted actually apply to all
files. I am the sole author of these files and clearly intend, and
have always intended, for the grant of permission to apply to them.
the difference of pointers is a signed type ptrdiff_t; if it is only
32-bit, left-shifting it by 30 bits produces undefined behavior. cast
the difference to an appropriate unsigned type, uint32_t, before
shifting to avoid this.
the a64l function is specified to return a signed 32-bit result in
type long. as noted in the bug report by Ed Schouten, converting
implicitly from uint32_t only produces the desired result when long is
a 32-bit type. since the computation has to be done in unsigned
arithmetic to avoid overflow, simply cast the result to int32_t.
further, POSIX leaves the behavior on invalid input unspecified but
not undefined, so we should not take the difference between the
potentially-null result of strchr and the base pointer without first
checking the result. the simplest behavior is just returning the
partial conversion already performed in this case, so do that.
Rich Felker
Daniel Sabogal
Hannu Nyman
Daniel Sabogal
Szabolcs Nagy
Felix Janda
Natanael Copa
Olivier Brunel
Bobby Bingham