7 ms·
> Zig does not, and will not, have VLAs in the language spec. Instead, you can allocate a slice on the heap. If you want to have the data on the stack, use an a
by mananaysiempre 1y ago
> Zig does not, and will not, have VLAs in the language spec. Instead, you can allocate a slice on the heap. If you want to have the data on the stack, use an array as a bounded backing store, and work with a slice into it[.]
Too bad, aligned byte-typed VLAs (and a license to retype them as a struct) are what you need to get stack allocation across ABI boundaries the way Swift does it. (A long long time ago, SOM, IBM’s answer to Microsoft’s COM, did this in C with alloca instead of VLAs, but that’s the same thing.) I guess I’ll have to use something else instead.
- rvrb 1y agoI think there may be room to expand this implementation to support such a use case. Right now it enforces an `.auto` layout of the struct provided in order to ensure alignment, but its easy to imagine supporting an `extern struct` with a defined layout. Conceivably, an implementation of this `ResizableStruct` that uses an array buffer as backing rather than a heap allocation, and supports the defined layout of an extern struct, could be used to work across the ABI
- throwawaymaths 1y agoyou can certainly allocate on the stack (like alloca). you just have to overallocate a compile-time known size and have some sort of fallback mechanism or fail if the size requested exceeds the amount created. moreover since the stack allocator is just an allocator, you can use it with any std (or user) datastructure that takes an allocator.
- AndyKelley 1y agoNote that not having runtime-known stack allocations is a key piece of the puzzle in Zig's upcoming async I/O strategy because it allows the compiler to calculate upper bound stack usage for a given function call. At a fundamental level, runtime-known stack allocation harms code reusability. Edit: commenters identified 2 more puzzle pieces below, but there's still one that didn't get asked about yet :P
- Conscat 1y agoDoes anything stop a user from doing this with inline assembly?
- AndyKelley 1y agoWisdom
- AshamedCaptain 1y agoHow does this work given... recursion? Even on languages without VLAs one can implement a simulacra of them with recursion.
- AndyKelley 1y agoAll Zig code is in one compilation unit, so the compiler has access to the entire function call graph. Cycles in the graph (recursion) cause an error. To break cycles in the graph, one must use a language builtin to call a function using a different stack (probably obtained via heap allocation).
- atmikemikeb 1y agowhat about extern functions?
- AndyKelley 1y agoZig's linker will calculate this information automatically in most cases when statically linking (via analysis of machine code disassembly). Otherwise, there is a default upper bound stack value, overridable via user annotation.
- dev-ns8 1y agoDoes this mean it's impossible in Zig to do strictly Stack related recursion and just by the mere inclusion of a recursive function your implicitly getting heap allocations alongside?
- h4ck_th3_pl4n3t 1y agoI am wondering if this is more of an unclearly defined memory ownership problem rather than a problem of what types you have to use to interact with C ABIs or FFI calls. I mean you could also just abstract the allocation away and handle it after the function pointer to your bridge, right?
- pjmlp 1y ago> A long long time ago, SOM, IBM’s answer to Microsoft’s COM, did this in C with alloca instead of VLAs, but that’s the same thing. Was kind of the other way around, given the whole OS/2 versus Windows history, and that COM started as the evolution of OLE and VBX technologies, Windows 9X and Windows NT weren't as COM heavy as OS/2 was with SOM. There was no COM to worry about on Windows 3.x back in 1991. https://www.edm2.com/index.php/SOM_%26_DSOM_-_An_Introduction https://www.edm2.com/index.php/SOM_%26_DSOM_-_An_Introductio... Also SOM was so much better, bettwen C++, Smalltalk and C, with support for meta-classes and proper inheritance implementation across such disparate languages.