I believe this is correct. I don’t know anything in Zig that unwinds the stack (that is, recovers the state of a previous frame). It is mentioned in the std library, but I don’t know in which circumstance Zig itself does it. Of course, if you call into C++ code, then it will do exceptions, but they are not initiated by Zig.
There is, however, stack tracing, that is, recording which functions were called, in order. Zig doesn’t do anything special, it walks the stack according to the platform prescribed way. For Windows, that information is in the unwind tables, which lives in the .pdata section, even though you don’t necessarily need to use it for unwinding. Zig and debuggers will use this information to find where the return address is within the stack. I believe to get your code to work with stack traces, you just need to write an approppriate entry in this table. However there is no mechanism for writing to the table after the program is loaded, so you need to write during building.
For Linux, all I know is that this information is called call frame information (CFI), and it lives in the DWARF file.
Other than messed up stack traces, I think your code will work, regardless of the function returning an error.
If you call into external functions on windows, you have to be careful with the TIB, otherwise Windows will think you caused a stack overflow. I talked about it here.
With all that said, there’s a reason why Go abandoned this approach. It’s not really performant. It’s much better to just know the stack size you need for your function, and allocate it all up front. I also talked about this in the linked discussion. It’s ridiculous that in 2026 we still don’t know the stack usage of our functions. The compiler needs to know this, except for the obvious corner cases, like recursive functions, so why doesn’t it just give it to us? It’s great that Zig is tackling this, but this should have been standard practice long before Zig even showed up.
1 Like