Repository navigation
undefined is not set to 0xAA pattern in Debug mode #25942
Description
Activity
- addedbugObserved behavior contradicts documented or intended behaviorObserved behavior contradicts documented or intended behavior
on Nov 16, 2025 The documentation says:
However, this behavior is only an implementation feature, not a language semantic, so it is not guaranteed to be observable to code.
This is vague enough to be ignored by newbies (me including). An example of such absence of guarantee would improve the documentation.
An example of such absence of guarantee
I think it's mainly talking about other compiler implementations and release modes and such; in other words, saying that the Zig language specification does not guarantee this.
Put differently: this is indeed a bug in the compiler (your report is entirely valid), but it doesn't mean we're implementing the (hypothetical) Zig language specification incorrectly; only that there is a bug in a debugging aid our compiler provides.
Reacted by truly-not-takenDuplicateRelated to #24100?I fail to see how this is a backend bug, there's no way to fill in the relevant info from the frontend:
--- a/src/codegen/x86_64/CodeGen.zig +++ b/src/codegen/x86_64/CodeGen.zig @@ -177058,7 +177058,9 @@ fn airBr(self: *CodeGen, inst: Air.Inst.Index) !void { try self.getValue(block_tracking.short, br.block_inst); break :dst block_tracking.short; }; - try self.genCopy(block_ty, dst_mcv, try self.resolveInst(br.operand), .{}); + try self.genCopy(block_ty, dst_mcv, try self.resolveInst(br.operand), .{ + .safety = ???, + }); break :result dst_mcv; };
Reacted by Matthew Lugg and truly-not-taken- addedfrontendTokenization, parsing, AstGen, Sema, and Liveness.Tokenization, parsing, AstGen, Sema, and Liveness.and removedarch-x86_6464-bit x8664-bit x86
on Nov 17, 2025
Zig Version
0.15.2
Steps to Reproduce and Observed Behavior
An
undefinedin a mildly complex expression is not set to a debug value of 0xAA pattern.On my linux-x86_64 machine the actual value of
foois sometimes 0x00000001 and sometimes some other garbage.Documentation implies that
undefinedbytes are set to 0xAA.Relevant forum post: https://ziggit.dev/t/reading-a-filled-nullable/13037/9
Expected Behavior
undefinedis 0xAA in safety-checked modes even if it comes from a complex expression.If this actually works as intended I expect the documentation to explain it.
I understand that accessing
undefinedis Illegal anyway. My concern is usefulness of 0xAA to detectundefinedwhen debugging.