Isaac Freund

> @ifreund can you double check with `valgrind` that zig is not doing anything fishy? valgrind log ``` valgrind --leak-check=full zig-git build-exe -lc -lexpat test.zig ==19445== Memcheck, a memory error...

>try this. should be OK because this applies only to building zig1.o Tried and confirmed that it fixed the issue for me at least. Should this be PR'd?

Here's what I get from the uname syscall on my machine using the following code: ```zig const std = @import("std"); pub fn main() !void { std.debug.print("{}\n", .{std.os.uname()}); } ``` ```...

@MasterQ32 both your code snippets are invoking UB with the current stage1 compiler implementation and spec defined by that implementation. Relevant bits from the llvm language reference: On load IR...

@Jarred-Sumner yes, the 4th padding byte of e.g. a `u24` would be left undefined currently. That's another decent argument in favor of defining the padding to be zeroed. That doesn't...

@jibal There is no language spec currently. There is documentation, but it is incomplete. For things not covered by the documentation, an accepted language proposal, or similar all we have...

The proper fix is *probably* adding `-lc_nonshared` to `libcFullLinkFlags()` in `src/target.zig` if targeting glibc. I would like to understand exactly what's happening here though before doing that.

On my glibc 2.32 void linux system `/usr/lib/libc.so` appears to be a linker script which pulls in `libc_nonshared.a`: ``` /* GNU ld script Use the shared library, but some functions...

> (except for bitcasts for which Zig is overly strict right now) Note that `@ptrCast()`ing can be used to work around this and is currently the only way I know...

@mingodad you'd be better off looking at the self hosted parser in `lib/std/zig/parse.zig`. The grammar in this repo is correct and `defer` does not allow a `Payload`.