If we have just created cache_dir_path, then there's no `tmp` dir
there, and
cache_dir.createFile(io, "tmp/libfuzzer.log", .{ .truncate = false })
fails.
Tested via
$ zig version
0.16.0
$ zig build --zig-lib-dir ~/p/zig/lib/ --fuzz
`setFileOwner` declared `SetOwnerError!void` but its vtable method
returns the wider `SetFileOwnerError!void` (adds `NameTooLong` and
`BadPathName`), so any call through the wrapper fails to compile.
`setTimestampsNow` dispatched to `io.vtable.fileSetTimestamps` with
`(Dir, []const u8, Dir.SetTimestampsOptions)`, but that vtable entry
takes `(File, File.SetTimestampsOptions)`. The intended target is
`dirSetTimestamps`, whose signature matches the call site.
The previous approach had a few downsides:
1. You couldn't set the alignment of the internal buffer. Many callers in
the standard library trying to use this for a small vec style
optimization worked around this by setting the alignment for
the struct itself, this ends up very verbose and also assumes a
specific layout for the struct which isn't guaranteed.
2. It was generic over the size of the buffer. This type is used a lot in
std with various sizes.
3. It has an awkward API where you had to call get which mutated the type
unlike all other allocators, and then had a runtime check to make sure
you didn't get this wrong.
The new approach resolves all of these issues by just taking the buf as
an argument.
This is particularly amenable to smallvec style optimizations: you can
just declare the buf as an array of the item you want to allocate to get
the exact minimum size.
This commit adds `dup2` and `dup3` based on musl. Zig already has
wrappers for the syscalls, but musl's implementation checks for a rare,
temporary race condition with dup2/3 and `open`. Like musl, this
implementation adds a fallback for dup3 if the syscall isn't available.
Contributes to: #30978
Before:
* test-zigc: run libzigc unit tests (part of test-modules)
* test-libc: run libc-test cases
Now:
* test-libc: run libc API unit tests (part of test-modules)
* test-libc-nsz: run libc-test cases
libc API unit tests (previously referred to as libzigc unit tests) now run for
all supported targets, even those we don't provide libzigc for. The idea is that
this will help us catch bad assumptions in the unit tests, as well as bugs in
other libcs.
I considered this setup:
* test-c: run libc API unit tests (part of test-modules)
* test-libc-nsz: run libc-test cases
* test-libc: both of the above
However, I do not like it because it gives a false sense of security; the full
module and C ABI test suites are still liable to catch libzigc bugs that test-c
and test-libc-nsz might not. So contributors should just run the test steps
outlined in https://codeberg.org/ziglang/zig/issues/30978.
Co-authored-by: rpkak <rpkak@noreply.codeberg.org>
For a test target with link_libc = null, we need to skip it if we would
implicitly link libc because the target requires it or because we don't yet have
a syscall layer for it.
This is distinct from the question of whether the target formally considers libc
to be the only stable syscall interface; for example, FreeBSD and NetBSD have
stable syscalls, but we don't yet have syscall layers for them in std.os.
Two mistakes I made when translating from the C header:
- The timeout and userspace_address2 pointers should be nullable.
- futex_wait() and futex_wake() are defined as static functions and
therefore not available as exported symbols. They're just thin
wrappers around futex() anyway so that's fine.
I'd have preferred if `vtable.futexWait` returned `error.Timeout`, since
all the OS-level APIs provide it. However, if I keep the vtable untouched,
I had to determine the timeout case by post-checking the deadline.
It's fine functionally, but one extra syscall that be avoided at
cost of changing the vtable and all the futex implementations.
@SizeOf(@typeInfo(T)) for any u{n} seems to give sizes of u32, u64, u128
and so on, depending on what size x fits into. This causes problems with
'>>' if x isn't exactly one of those sizes.
@typeInfo(@TypeOf(x)).int.bits gives a more accurate size.
From mlugg: this commit originally also added the same coverage to the
aarch64-linux-release script, but that caused the aarch64-linux-release
job to time out, so that change has been omitted for now.
nektro