Zig 0.9.1 update#29
Conversation
Fix for Zig std.mem.Allocator changes
|
Also pinging @marler8997, who may also be interested in these changes |
| var seed: [std.rand.DefaultCsprng.secret_seed_length]u8 = undefined; | ||
| try std.os.getrandom(&seed); | ||
| break :blk &std.rand.DefaultCsprng.init(seed).random; | ||
| break :blk &std.rand.DefaultCsprng.init(seed).random(); |
There was a problem hiding this comment.
I believe this is a bug. The instance of DefaultCsprng must outlive the reference to it.
There was a problem hiding this comment.
Oh good catch @marler8997. Presumably the tests will fail until this is modified to return the value rather than address. Unfortunately I'm still not sure why the tests fail to compile.
There was a problem hiding this comment.
Haven't tracked this down entirely yet, but the compilation failure appears to originate from the final test in main ("Connecting to client.badssl.com with a client certificate").
Specifically, some piece of code that is compiled only when the options struct passed to client_connect has a client_certificates value.
Still sorting through trying to find something more useful.
There was a problem hiding this comment.
I debugged this test failure a while ago and I believe it was just because the certificate the test is expecting is different than what the website currently serves up. The test probably shouldn't expect the certificate never to change, rather, just verify it's valid.
There was a problem hiding this comment.
For the tests that fail at runtime, I believe you are correct. However I was talking about the OP's issue mentioned in the PR description, where the tests fail to compile; the compiler crashes with an error similar to this (sorry this was probably unclear in my original comment):
Code Generation [1750/2032] std.mem.Allocator.reallocAdvancedWithRetAddr... broken LLVM module found: Call parameter type does not match function signature!
%229 = getelementptr inbounds { %"?[]const u8", i16 }, { %"?[]const u8", i16 }* %0, i32 0, i32 0, !dbg !36943
%"?[]align(8) u8"* call fastcc void @std.mem.Allocator.resize.403(%"?[]const u8"* sret(%"?[]align(8) u8") %229, %std.mem.Allocator* %2, %"[]u8"* %23, i64 %227), !dbg !36943
This is a bug in the Zig compiler.thread 821 panic:
Unable to dump stack trace: debug info stripped
Just finished looking at this in more detail, and the issue originates from the sign function in pcks1-1_5.zig, line 128:
return allocator.resize(
enc_buf.ptr[0 .. rsa_result.limbs.len * @sizeOf(usize)],
signature_length,
);the allocator.resize call is what's causing the compiler crash. I'm not entirely sure why; could be a data type/alignment issue, since the original value that enc_buf was derived from is casted from its original type to []u8 before being passed in? Could also be the code is fine and it is exclusively the result of a (stage 1) compiler bug, in which case I have no idea.
|
Closing in favour of #27 |
5 participants
Some more fixups for Zig 0.9.1 on top of some of @nektro's changes from #27
Most of these additional changes relate to building tests. However, when attempting to build tests with Zig 0.9.0, the compiler crashes during codegen
edit: update Zig 0.9.0 -> 0.9.1