#is zig abi stable with the same compiler
1 messages · Page 1 of 1 (latest)
while it may work in some cases you should not expect it to work.
For example in the future there are plans to randomize struct layouts in debug mode.
If you need ABI compatability use the c abi with extern structs and functions or your own serde
no, Zig doesn't guarantee ABI stability across compilation even when using the same compiler, in practice, I don't think it actively swaps fields around to discourage relying on ABI stability
%%4336 like I noted it is planned
doesn't have accepted tag
unlucky
i wonder why not add stable abi at least with the same compiler
having to copy stuff over C ABI boundary is kind of annoying
don't have to copy if the shared/base state is defined as extern struct, instead of it being just a data transfer channel
Because having a stable abi is an insane burden, and could lead to massive issues when they want to fix something, but can't modify the ABI. I think very few of the people asking for a stable ABI understand how hard it is to have a good stable ABI. And the biggest issue then is that you can't make it better, because that'd make it unstable.
you'd just end up with yet another flawed, C like ABI
just fix it in the next version of compiler, i mean stable abi within the same compiler version
working with extern structs is not fun, can't even have slices
one way is to add methods to the struct to wrap underlying state in zig friendly types. Like slice can be returned with no copy overhead
it is kinda more annoying to have 2 times more structs
maybe you can use comptime to generate extern struct
I wish slice had an extern ABI. LLVM and Linux both have well defined concept of slice.