We know that x != 0 and extractor.exponent == 0 at the bottom
of the function, meaning mantissa must be != 0.
And the `extractor.exponent = exponent + 1;` store overwrites
the store on the line above. (Presumably, the line above meant
to shift `mantissa` instead.)
No behavior change.
The user group id (GID) is a different concept than the process group id
(PGID), here we obviously want the PGID. From the POSIX spec:
> If pid is 0, status is requested for any child process whose process
> group ID is equal to that of the calling process.
A test covering that case will be added in the next commit.
I noticed this while trying to compile a standalone lagom libm.so from
LibC's math.cpp for testing.
Before, this would fail with a "conflicting declaration" error since
the fegetround() declaration wasn't `extern "C"`.
Instead of defining LITTLE_ENDIAN and BIG_ENDIAN ourselves, we should
use the definitions from the compiler.
Additionally, we don't have <bits/endian.h>, so it's never correct to
include that header.
These definitions appear to be unused and are not required by POSIX.
They appear to be specific to OpenBSD and do not seem to exist on any
other system.
We don't check for feature test macros in any other LibC header, and
especially not for _GNU_SOURCE or _BSD_SOURCE. With no feature test
macro defined, this header would previously essentially be empty.
POSIX doesn't seem to require any feature test macros for this header
either.
Either of these two parameters being null would previously invoke UB.
The Kernel still rejects null argv so this commit only makes calls with
a null `envp` actually work.
I'm not sure why they were defined elsewhere, POSIX tells us where they
belong.
This fixes the coreutils port, which currently fails with an 'undeclared
function' error.
We already use pwritev to implement writev, so let's do the same for
readv. This resolves the awkward situation of having pwritev but not
preadv, which affects Zig for instance.
The tests show that mod(a, b) takes on the sign of b while
a % b takes on the sign of a. As b is usually a positive constant,
mod() is useful when you want a guaranteed positive result.
mod() matches the semantics of % in Python.
Also, mod(a, b) == mod(a, abs(b)) modulo b, while
a % b != abs(a) % b modulo b. So mod() makes it easier to get a
guaranteed-positive result even if the sign of b is unknown.
No behavior change.
According to POSIX, we must define `timespec`, but we _may_ include
`time.h` in doing so. Compiling ScummVM 2.9.1 against LibC was failing
because compared to glibc, we were pulling in `time.h` too early which
caused conflicts in ScummVM's `common/forbidden.h`.
515f31339c incorrectly made getopt only reset its state when `optind`
is set to 1. However, the Linux man page says that setting it to 0 also
reinitializes its state and additionally checks for some GNU extensions.
stress-ng relies on this behavior.
The POSIX man page only says that setting it to 0 results in undefined
behavior.
Removed the impossible assertion of sizeof(double) == sizeof(long
double) in strtold. This fixes the crash but suffers from lack of
precision.
Our eisel-lemire implementation on FloatingPointStringConversions needs
a big overhaul to work properly with long doubles, especially with x87
80-bit extended precision format.
Fixes#25791
Nico Weber