After decryption, TLS 1.3 plaintext is trimmed of zero padding, then
the last byte is read as the content type.
But when the plaintext was entirely zero padding, we got a
"thread panic: integer overflow at msg.len - 1" error. That could be
triggered by any server to crash the client.
`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.
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>
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.
This required a thorough audit of every syscall wrapper in std.os.linux, so
while I was here, I fixed some minor arch-specific bugs, improved some types,
simplified some casts, and deleted some dead code.
Note that lseek() in particular is still broken for n32 and x32 after this
commit; this wrapper will require some special-casing in the arch bits due to
its unusual return type width.
closes https://github.com/ziglang/zig/issues/22464
closes https://codeberg.org/ziglang/zig/issues/31597
For some of these functions and most targets this changes nothing,
either because long double and double are not equivalent or because
llvm did function deduplication.
But e.g. on aarch64-windows-gnu, ucrt provides hypot, but not hypotl.
Now hypotl calls hypot from ucrt instead of including the std.math.hypot
implementation in zigc.
Very trivial functions (like nanl) are not changed, because a function call would probably make this function more complex.
...but not in the way you'd expect. We were actually tracking them in
cases where we shouldn't have been! We cannot track a declaration if its
parent namespace has been lost, because that will cause analysis
failures immediately, but if we excluded a type from the mapping due to
a major change (such as a struct turning into a union, or a field being
added), we were still including any trackable instructions inside the
container's field expressions (e.g. struct field type expressions). This
meant we were tracking a type declaration while losing tracking on its
parent namespace, with predictably disastrous results.
Oh, also, tracking for opaque types was just totally wrong (I think this
was a typo from a while back). We could map it to things other than
opaque declarations, and we never mapped declarations inside opaques.
So, uh, I fixed that too.
Frank Denis