Uncaught undefined behavior when returning pointers to stack memory.

[tecanec]

Zig Version

0.10.0-dev.543+cfceec15e

Steps to Reproduce

As title says. Simply return a pointer to something stack-bound.

Expected Behavior

It makes sense that reading the contents of the returned pointer would be undefined behavior. The contents have gone out of scope, after all. However, the programmer might not realize what they're doing; I accidentally did this yesterday by forcing a struct's initializing function into runtime without realizing it, and then calling it from another function and returning a pointer to its result, which I thought would reside in constant memory.

Actual Behavior

This is uncaught unexpected behavior, and the docs admit this. However, this still caught me off-guard when my game's text renderer suddenly returned error.OutOfMemory while I was working with callbacks that hadn't even been called yet. It took me a relatively long (by Zig's standards) debugging session to realize that the callbacks were using runtime-only features, which extended itself to that no-longer-constant-memory struct literal with callback fields, which would eventually cause the text renderer to fail as it attempted to display a multi-quintillion-byte string from that same struct.

While technically not a bug, I definitely think that this uncaught undefined behavior has proven itself to be an issue. Uncaught errors escalating like this doesn't meet Zig's high standards in this regard, and the unclear connection between the error itself and the root of its cause is bad for maintainability.

Perhaps we could add a runtime check to see if a returned pointer points to popped stack memory?

PS: I realize that this may be blurring the line between "bug repport" and "language proposal", the latter of which ZLF aren't accepting at the moment. If this is delving too far into the "language proposal" side of things, then I apologize in advance and hope that I'm not too much of a bother.

[ifreund]

This is already covered by #2301 and #3180 I believe.

[tecanec]

This is already covered by #2301 and #3180 I believe.

Ah, sorry.