wasip2's wasi-cli WIT dep is pinned at 0.2.0, whose exit interface only has the boolean exit function. wasip2.c and the generated headers only import that.
As of wasi 0.2.12, wasi:cli/exit gained a stable exit-with-code function that propagates the real exit code instead of collapsing every nonzero code to a boolean failure signal.
Since wasip2's exit()/_Exit() only call the boolean exit, any nonzero exit code from a wasm32-wasip2 program is lost at the host boundary — affects every language linking wasi-libc, not just one. See uutils/coreutils#13625 for a concrete workaround that had to call the WIT import directly.
Could the wasip2 exit path bump its wasi-cli dep to 0.2.12+ and call exit-with-code unconditionally? This is important because the API will match wasip3's behavior.
wasip2's wasi-cli WIT dep is pinned at 0.2.0, whose exit interface only has the boolean exit function. wasip2.c and the generated headers only import that.
As of wasi 0.2.12, wasi:cli/exit gained a stable exit-with-code function that propagates the real exit code instead of collapsing every nonzero code to a boolean failure signal.
Since wasip2's exit()/_Exit() only call the boolean exit, any nonzero exit code from a wasm32-wasip2 program is lost at the host boundary — affects every language linking wasi-libc, not just one. See uutils/coreutils#13625 for a concrete workaround that had to call the WIT import directly.
Could the wasip2 exit path bump its wasi-cli dep to 0.2.12+ and call exit-with-code unconditionally? This is important because the API will match wasip3's behavior.