It is now ignored for inputs from the corpus to ensure the filesystem
and process corpus stay in sync. For other (nondeterministic) inputs the
input builder is now reset.
The first issue is that when len(Sn) >= 128,
we perform Sn xor D instead of the Sn xorend D
that is specified in RFC 5297.
The second issue is that we truncate the Sn
if it is larger than 4096 bytes, which could
lead to collisions between inputs. We solve
this by absoring the Sn into the CMAC state
perform the last 16 bytes, xoring those 16
bytes with D as described in the first issue,
and then updating and squeezing the CMAC.
As established in 048e38624e and d70bd0b37e, mutexes should use a strong
cmpxchg when attempting to lock to guarantee that they actually succeed
if they aren't locked yet.
Also deletes an unused near-duplicate of `mutexLock()`.
The `cmpxchgWeak` in `setIpcFile` could lead to the IPC file not being set
even though there's still a slot available because one or more slots were
spuriously skipped.
The `cmpxcheWeak` in `serialize` could lead to an unused IPC slot not
being locked and used even though it could be.
Having `std.Io.Uring` contain OpenError error set
allows handling of OperationUnsupported specifically for `.openat`,
while avoiding propagating this error to the more general
`File.OpenError`.
This more specific subset also eliminated 2 unreachable prongs that
previously inherited from `File.OpenError`.
Added comments when handling OperationUnsupported, making it clear it is
an unexpected error when TMPFILE bit is not set.
- plain old data ftw
- 177K -> 151K
- data bypasses Sema
This change is not really important but it was nice to explore best
practices for data like this.
When I measured building the compiler, I found no statistically
significant difference in compilation time.
In #31086, the `std.time.Timer` struct was removed, but this broke the last few programs that used it, those being the benchmarking programs for `std.Random`, `std.hash`, `std.crypto` and `std.unicode`. One more is `zig/perf_test.zig`, but as far as I can tell, that one is broken due to changes in file import rules too, unless I'm launching it wrong.
I also spotted some performance and benchmarking issues with the RNGs, detailed in #31554.
Reviewed-on: https://codeberg.org/ziglang/zig/pulls/31553
Reviewed-by: Andrew Kelley <andrew@ziglang.org>
Co-authored-by: UraniaZPM <uraniazpm@noreply.codeberg.org>
Co-committed-by: UraniaZPM <uraniazpm@noreply.codeberg.org>
`switch` statements on types >128bits are now lowered to conditionals.
This is necessary because Zig lowers integers with more than 128 bits to
bigints, which are not 'native' integers and thus cannot be used as case
values.
128-bit integers get special treatment because Zig will emit actual 128bit
ints if they are supported by the target. They still *may* be lowered to
bigints though, e.g. for 32-bit targets or MSVC. To solve this, this commit
adds a bunch of switch macros to `zig.h` which will either resolve to an
actual `switch` statement or to conditionals. The `if` statements this
approach can generate are not as optimal as they could be but I think this
is a good trade-off since the generated `switch` statements are still the
same as the ones generated for smaller integers. Also the macros result
in pretty readable code.
`modf` function was generalized and renamed to `modfGeneric`, `modf` and
`modff` provide the appropriate type while calling that function. The
unit tests were also generalized so they can be reused for different
float types.
Both `modf` and `modff` were tested after making these changes:
```
$ stage4/bin/zig build test-libc -Dlibc-test-path=<LIBC-TEST-PATH> -Dtest-filter=modf -fqemu -fwasmtime --summary line
Build Summary: 921/921 steps succeeded
```
```
stage4/bin/zig build test-libc -Dlibc-test-path=<LIBC-TEST-PATH> -Dtest-filter=modff -fqemu -fwasmtime --summary line
Build Summary: 369/369 steps succeeded
```
The behaviour regarding special cases differs between `libc` and Zig's
`stdlib` for `modf`, so the implementation couldn't be a straightforward
calling of `stdlib` function.
Other than the obvious documented differences, I also had problems with
the `INVALID` flag being raised while running `libc-test` suite on riscv
arch through qemu. The solution was to test if the argument is `NaN`,
and then return a quiet `NaN` if so.
Passing tests, that should include all the special cases to be wary of,
were also added.
Test results:
```
$ stage4/bin/zig build test-libc -Dlibc-test-path=<LIBC-TEST-PATH> -Dtest-filter=modf -fqemu -fwasmtime --summary line
Build Summary: 921/921 steps succeeded
```
This regressed back in https://github.com/ziglang/zig/pull/25154. I
didn't get around to fixing it until now, so a few instances of the
warning snuck into the repo over the past few months, which were fixed
in the previous commit. The regression has not appeared in a tagged
release though, so this is not a breaking change in 0.16.0.
Resolves: https://codeberg.org/ziglang/zig/issues/31049
Kendall Condon