Adds missing errors CONNECTION_REFUSED for netConnectIpWindows and
CONNECTION_RESET for both netReadWindows and netWriteWindows. I'm able
to induce these 3 errors on my Windows 11 machine.
Even though these registry mentions are supposed to be in a comment they
seem to still be interpreted by gcc.
Alternatively one could try to make zig not include comments in assembly
blocks when generating C code.
In function 'os_linux_x86_syscall6__6685',
inlined from 'os_linux_copy_file_range__4300' at zig2.c:396643:7,
inlined from 'link_MappedFile_copyFileRange__14079.isra' at zig2.c:289222:10:
zig2.c:396692:2: error: invalid 'asm': operand number missing after %-letter
396692 | __asm volatile(" push %[args56]\n push %%ebp\n mov 4(%%esp), %%ebp\n mov %%edi, 4(%%esp)\n // The saved %edi and %ebp are on the stack, and %ebp points to `args56`.\n // Prepare the last two args, syscall, then pop the saved %ebp and %edi.\n mov (%%ebp), %%edi\n mov 4(%%ebp), %%ebp\n int $0x80\n pop %%ebp\n pop %%edi": [ret]"=r"(t5): [number]"r"(t6), [arg1]"r"(t7), [arg2]"r"(t8), [arg3]"r"(t9), [arg4]"r"(t10), [args56]"rm"(t2): "memory");
| ^~~~~
zig2.c:396692:2: error: invalid 'asm': operand number missing after %-letter
zig2.c:396692:2: error: invalid 'asm': operand number missing after %-letter
zig2.c:396692:2: error: invalid 'asm': operand number missing after %-letter
zig2.c:396692:2: error: invalid 'asm': operand number missing after %-letter
Followup to #30769
I grepped for `try .*toOwnedSlice` and checked all of them by hand.
Fixes a bunch of memory leaks removes usages or `errdefer` and `vars` in some places. I also switched array_list.Managed to ArrayList where it was convenient.
Reviewed-on: https://codeberg.org/ziglang/zig/pulls/32001
Reviewed-by: Andrew Kelley <andrew@ziglang.org>
UTCTime years in the range 50-99 must map to 1950-1999, but the
parser unconditionally added 2000, producing dates 100 years in the
future.
This caused verify() to accept certificates whose validity actually
expired decades ago.
Change that to match what OpenSSL, BoringSSL, etc. do
AsconXof128 and AsconCxof128 were applying the padding in update()
calls. That was totally fine for one-shot hashing, but not for
streaming (multiple update() calls before finalization).
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>
Alex Rønne Petersen