Odd behavior of undefined Optional value when passed through anyopaque pointer

[CodeingerCat]

Zig Version

0.14.0

Steps to Reproduce and Observed Behavior

So, I was trying to use an optional field to keep track of whether a filed in a structure should be 'usable' by using a 'null' value to flag its 'un-usability', and I ran across this odd behavior. This behavior occurs when an Optional field in a structure is set to undefined, where depending on what optimization level that is used, it ends up with a different result when checking if the value is 'null' before and after being passed through an anyopaque pointer cast and back.

const std = @import("std");

pub const std_options = std.Options{
    .log_level = .info,
};

const TypeHolder = struct {
  value: ?u32,
};

pub fn main() !void {
  var a = TypeHolder{.value = undefined};
  const p_a = &a;
  std.log.info("Before: {*} {}", .{p_a, p_a.value == null});
  const p_b: *anyopaque = @ptrCast(p_a);
  const p_c: *TypeHolder = @ptrCast(@alignCast(p_b));
  std.log.info("After: {*} {}", .{p_c, p_c.value == null});
}

Debug
info: Before: main.TypeHolder@d148dffcb0 true
info: After: main.TypeHolder@d148dffcb0 true

ReleaseSafe
info: Before: main.TypeHolder@c1261ffbf8 false
info: After: main.TypeHolder@c1261ffbf8 true

ReleaseSmall
info: Before: main.TypeHolder@7c80fffea8 true
info: After: main.TypeHolder@7c80fffea8 true

ReleaseFast
info: Before: main.TypeHolder@dcea3ff900 false
info: After: main.TypeHolder@dcea3ff900 true

Expected Behavior

I was hoping it would set the value to not-null with an undefined value, but I'm not sure exactly what the correct behavior would be after a bit more thought.

This might be related to these 2 issues, but I'm not sure what the correct behavior is based on these either:

• Unwrapping undefined optional is not safety-checked in safe modes #22215
• Setting optionals to undefined defaults to null in debug mode #8333

[CodeingerCat]

If the target platform matters here, I was testing this on Windows.

[alexrp]

Your code is invalid because it depends on the value of an undefined field. Please see the relevant language reference section: https://ziglang.org/documentation/master/#undefined

undefined is not an observable state as in e.g. JavaScript.

[CodeingerCat]

Sorry for the clutter. I confused myself with this one and have now realized I probably meant to do TypeHolder{.value = @as(u32, undefined)} instead. For some reason, I thought setting the filed to undefined would set it as a not null undefeind value instead of 'nullness' and value both being undefined.