Returning pointer to a local const struct unexpectedly yields valid data

[zpaceway]

Zig Version

0.14.0

Steps to Reproduce and Observed Behavior

When you return a pointer to a local const-qualified struct, Zig does not allocate that binding on the stack by default. As a result, the pointer remains valid after the function returns—even though it wasn’t explicitly moved to the heap or marked comptime. This behavior feels surprising and can lead to subtle bugs when you expect a dangling pointer.

const std = @import("std");

const Foo = struct {
    bar: i64,
    data: [10]u8,
};

fn createFooVar() *Foo {
    var foo = Foo{
        .bar = 2,
        .data = [_]u8{0,1,2,3,4,5,6,7,8,9},
    };
    return &foo;
}

fn createFooConst() *const Foo {
    const foo = Foo{
        .bar = 2,
        .data = [_]u8{0,1,2,3,4,5,6,7,8,9},
    };
    return &foo;
}

pub fn main() !void {
    const fooVar = createFooVar();
    const fooConst = createFooConst();

    std.log.info("fooVar (corrupted)      = {any}", .{fooVar});
    std.log.info("fooConst (still intact) = {any}", .{fooConst});
}

output

info: fooVar (corrupted)      = conv.Foo{ .bar = 140734223737152, .data = { 185, 248, … } }
info: fooConst (still intact) = conv.Foo{ .bar = 2,               .data = {   0,   1, … } }

Expected Behavior

Both createFooVar and createFooConst should yield corrupted data or compile-time errors when returning a pointer to a local binding.

Alternatively, only a value explicitly marked comptime should live beyond the function scope.

This discrepancy violates the expectation that plain const implies a runtime stack allocation. It would be helpful to clarify whether this is intentional or an oversight in the compiler’s allocation strategy.

[Rexicon226]

related: #23528

[nektro]

createFooConst returns a pointer to a local whose content is wholly comptime-known so it is stored in the rodata of the binary and thus an address to it being valid is intended, afaik

[zpaceway]

Yep, I know what is going on. My point is that foo isn’t marked with comptime anywhere, yet the compiler still treats it like a compile-time constant and makes it live beyond the function. That implicit promotion feels hidden imo.

[Rexicon226]

At the end of the day, your code is UB, so the compiler can do whatever it wants. I linked the issue tracking making these sorts of mistakes easier to catch with runtime checking, but your code is the problem here nevertheless. This "implicit promotion" has no semantic effects on the language, and wouldn't be noticeable if your code was well-formed.

[zpaceway]

You seem to be confused here. I wrote the code to crash on purpose so I could spot this hidden behavior. I expected it to crash with a dangling pointer, because of zig's no hidden control flow promise.

[zpaceway]

How a programming language handles this unwanted behavior, such as dangling pointers is crucial. We are talking about an issue that shut half of the internet down last week. The compiler should not do whatever it wants.

[mlugg]

I wrote the code to crash on purpose

Then you wrote incorrect code. Unchecked Illegal Behavior means that the compiler can and will do "whatever it wants". This is critical for optimization. The comptime semantics here are guaranteed, but if that guarantee was gone, then the compiler would still be allowed to do this.

If you need a crash, use something like @panic.