Content length based reading would only set the reader state to `ready`
once it returned EOF, but wrapping readers (such as decompressors)
may stop reading from the underlying source without receiving EOF.
In such cases the http reader state would stay set to
`body_remaining_content_length`, even though the entire body had been
read.
Fixes#30060
Co-authored-by: Andrew Kelley <andre@ziglang.org>
mingw,musl,wasi-libc: remove c files, that only provide functions already included in zigc
mingw: remove c files, that only provide functions, which are in ucrt
mingw: do not include mingw files/zigc functions on targets on which they in ucrt
- New Features
-- Multiprocess Fuzzing
The fuzzer now is able to utilize multiple cores. This is controllable
with the `-j` build option. Limited fuzzing still uses one core.
-- Fuzzing Infinite Mode
When provided multiple tests, the fuzzer now switches between them and
prioritizes the most effective and interesting ones. Over time already
explored tests will become barely run compared to tests yielding new
inputs.
-- Crash Dumps
Crashing inputs are now saved to a file indicated by the crash message.
It is recommended to use these files to reproduce the crash using
`std.testing.FuzzInputOptions.corpus` and @embedFile.
- Design
Each fuzzing process is assigned an instance id which has the following
uses:
* In conjunction with the pc hash and running test index, they uniquely
identify input files in the case of a crash.
* It is combined with the test seed for a unique rng seed.
* Instance 0 is solely responsible for syncing the filesystem corpus.
When new inputs are found, they are sent to the build server. It then
distributes the new input to the other instances. Each instance has a
concurrent poller managed by the test runner which sends received
inputs to libfuzzer. (note that this is affected by #31718 and so can
(rarely) deadlock)
For fuzzing infinite mode, the test runner now receives a list of tests
from the build server. The fuzzer runs tests in batches of one second,
approximated in cycles by the previous batch's run speed. Tests finding
new inputs or with few runs are given a higher run chance. The baseline
run chance is based off the recency of the last find and the number of
pcs the test has hit.
The closest namespace the pi/4 constant could belong to is `trig.zig` since
it's used across trig function implementations. On the other hand, chucking
`long double` bit slicing functions into `trig.zig` seems a little more
awkward, so they're put into their own namespace.
The implementation was ported from `musl`. Unit tests for `f80` and `f128` were also added.
`__cosl` was already implemented in `trig.zig` while working on `sinl`.
The changes were tested by running:
```
$ ./build/stage3/bin/zig build -p stage4 -Denable-llvm -Dno-lib
$ stage4/bin/zig build test-libc -Dlibc-test-path=<LIBC-TEST-PATH> -Dtest-filter='math.cosl' -fqemu -fwasmtime --summary line
Build Summary: 553/553 steps succeeded
```
The implementation was ported from `musl`. Unit tests for `f80` and `f128` were also added.
The changes were tested by running:
```
$ ./build/stage3/bin/zig build -p stage4 -Denable-llvm -Dno-lib
$ stage4/bin/zig build test-libc -Dlibc-test-path=<LIBC-TEST-PATH> -Dtest-filter=sinl -fqemu -fwasmtime --summary line
Build Summary: 553/553 steps succeeded
```
The logic was more or less ported from `musl`, with small adjustments
where it was convenient. The 'internal' `__tanl` function was implemented
in the `trig.zig` module along with other 'internal' trigonometric functions.
Now, the `tanl` implementation is precise enough to pass all the relevant `libc-test` suite tests:
```
$ ./build/stage3/bin/zig build -p stage4 -Denable-llvm -Dno-lib
$ stage4/bin/zig build test-libc -Dlibc-test-path=<LIBC-TEST-PATH> -Dtest-filter=tanl -fqemu -fwasmtime --summary line
Build Summary: 553/553 steps succeeded
```
The unit tests were also extended to include cases for `f80` and `f128`, and they're passing.
Additionally, add helper functions for fetching the sign+exponent
and top 16 bits of a f80/f128's mantissa.
We'll need these functions to implement `cosl`, `sinl`, `tanl`, and,
transitively, `sincosl`.
Seems like it was missed when implementing `rint`.
This was checked by running:
```
$ ./build/stage3/bin/zig build -p stage4 -Denable-llvm -Dno-lib
$ stage4/bin/zig build test-libc -Dlibc-test-path=<LIBC-TEST-PATH> -Dtest-filter=rint -fqemu -fwasmtime --summary line
Build Summary: 2209/2209 steps succeeded
```
The implementation was ported from `musl` to Zig code, and the `rint`
unit tests were generalized so they could be used for `rintf` as well.
This was checked both through unit tests and running `libc-test` suite:
```
$ ./build/stage3/bin/zig build -p stage4 -Denable-llvm -Dno-lib
$ stage4/bin/zig build test-libc -Dlibc-test-path=<LIBC-TEST-PATH> -Dtest-filter=rintf -fqemu -fwasmtime --summary line
Build Summary: 1657/1657 steps succeeded
```
The behaviour of `libc` `finite` functions is the same as Zig std's, so
the function basically delegates to `math.isFinite` and no new tests were
added. These functions are obsolete, but still part of `musl`.
No results are attached in this case as `libc-test` doesn't have tests for them.
The `frexp` implementation was generalized so it can be used for `f32`
and `c_longdouble` types as well.
The changes were tested by running:
```
$ ./build/stage3/bin/zig build -p stage4 -Denable-llvm -Dno-lib
$ stage4/bin/zig build test-libc -Dlibc-test-path=<LIBC-TEST-PATH> -Dtest-filter=frexp -fqemu -fwasmtime --summary line
Build Summary: 737/737 steps succeeded
$ stage4/bin/zig build test-libc -Dlibc-test-path=<LIBC-TEST-PATH> -Dtest-filter=frexpf -fqemu -fwasmtime --summary line
Build Summary: 369/369 steps succeeded
```
The changes were tested by running:
```
$ ./build/stage3/bin/zig build -p stage4 -Denable-llvm -Dno-lib
$ stage4/bin/zig build test-libc -Dlibc-test-path=<LIBC-TEST-PATH> -Dtest-filter=frexp -fqemu -fwasmtime --summary line
Build Summary: 737/737 steps succeeded
```
The tests were passing even when it was a straightforward calling of Zig
std library, but I wanted the `x is NaN` special case to match the
behaviour described in `libc` manpages, and for it to be consistent
with how infinities as arguments are handled in Zig.
The cmpxchg is there to recover alignment padding that isn't needed (which
can only be determined after the fetch-and-add that reserves it as allocated
memory). As cmpxchg tends to be a very expensive operation, it is actually
faster to introduce an additional branch here that checks if the cmpxchg
would be a noop (because all of the reserved alignment padding was in fact
necessary) and skips it if that's the case.
This does not measurably regress performance if the arena is only accessed
by a single thread and yields slight performance benefits for multi-threaded
usage. If the arena is commonly used for unaligned allocations, the perf
benefits are quite significant.
Co-authored-by: Jacob Young <amazingjacob@gmail.com>
Luna Schwalbe