Wasmtime does not seem to accept exit codes greater than 125. Is their any reason for this limitation? I couldn't find any relevant documentation.
See wasi_proc_exit in https://github.com/bytecodealliance/wasmtime/blob/main/crates/wasi/src/lib.rs
in POSIX, exit codes >= 128 indicate that the process was terminated by a signal, and 126 and 127 are used to report errors launching child processes. WASI doesn't yet have signals or ways to launch child processes, and we're not yet sure what they'll look like, so we're erring on the side of being conservative
Do you have a use case which needs exit codes > 125?
Thanks Dan. It does make sense.
I'm using the C API, and I would like to distinguish between a signal and a non-user trap. I don't think I'll need the exact signal, so I guess I can make the distinction from the trap message.
WASI doesn't have signals.
You can use wasmtime_trap_exit_status
to determine if the trap was caused by a proc_exit
or not.
bjorn3 said:
You can use
wasmtime_trap_exit_status
to determine if the trap was caused by aproc_exit
or not.
Thanks Bjorn, that's what I'm doing ATM, but it returns false if the exit code is > 125. Even though WASI doesn't have signals, I still need to distinguish an exit code of [126, 255] from, e.g., an unreachable trap, but I guess I have to use the error message for that?
When the exit code is in the range 126..=255, it isn't valid and you don't get an exit trap but an error trap.
You must not pass 126..=255 to proc_exit
.
bjorn3 said:
You must not pass 126..=255 to
proc_exit
.
I'm not the one supplying the WASI binary. I'm just trying to handle the case where it happens.
What application is it if I may ask?
I'm writing a WebAssembly/WASI analysis and I'm using some more or less random C programs compiled with WASI-clang as benchmarks.
Why would it return those strange exit codes?
bjorn3 said:
Why would it return those strange exit codes?
return -1
seems to be a pretty common pattern for indicating a program failure.
From the main function of course.
On one hand POSIX seems to reserve EXIT_FAILURE
as exit code for the purpose of calling exit
on an error: https://pubs.opengroup.org/onlinepubs/9699919799/functions/exit.html, which is defined as 1 in wasi-libc: https://github.com/WebAssembly/wasi-libc/blob/575e1579a4ebaa6dccb884ca657188a92982af23/libc-top-half/musl/include/stdlib.h#L88 The C specification states that returning a value from the main function is equivalent to calling exit
with the respective return value as argument: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf 5.1.2.2.3 Program termination
On the other hand POSIX does state that any value is allowed to be passed to exit
: https://pubs.opengroup.org/onlinepubs/9699919799/functions/exit.html
in practice, compliance with POSIX is very... handwavey.
which isn't even unexpected since in general it rarely specifies SHALL NOT, it only specifies SHALL and SHOULD, and in a way that allows a broad latitude of interpretation.
but like, my experience with experimenting with shells and the like which claim to be "POSIX-compliant" is that one should expect compliance with POSIX even on the points where it is clearly "do this" to be within a standard deviation, as it were, of interpretations.
I agree POSIX is handwavy in a lot of ways. So I think in this case, the question to ask is, if you could make exit(-1)
do anything, what would you want it to do?
I don't know of any code that does exit(-1)
myself, but apparently it happens
(deleted)
Last updated: Nov 22 2024 at 16:03 UTC