Wrong argument in clock_res_get causes Wasmtime to crash

[emugnier]

Test Case

fn main() {
    unsafe {
        match wasi::clock_res_get(5) {
            Ok(_r) => println!("it works"),
            Err(e) => println!("{}", e)
        }
    }
}

Steps to Reproduce

1. Compile with cargo build --target=wasm32-wasi --release
2. Run with wasmtime target/wasm32-wasi/release/wasi_test.wasm

Expected Results

The parameter id parameter is invalid (set to 5 in the test) and the Err case should be matched:

$ wasmtime target/wasm32-wasi/debug/wasi_tests.wasm
INVAL (error 28)

Actual Results

Wasmtime crashes with the following message:

$ wasmtime target/wasm32-wasi/debug/wasi_tests.wasm
Error: failed to run main module `target/wasm32-wasi/debug/wasi_tests.wasm`

Caused by:
    0: failed to invoke command default
    1: In func wasi_snapshot_preview1::clock_res_get at convert Clockid: Invalid enum value Clockid
       wasm backtrace:
           0: 0x165b - <unknown>!wasi::lib_generated::clock_res_get::ha1e6dbd916666170
           1:  0x43b - <unknown>!wasi_tests::main::h385d4fa4b68024d5
           2:  0x8ea - <unknown>!core::ops::function::FnOnce::call_once::h1cbd4d5094d04dd5
           3:  0x94e - <unknown>!std::sys_common::backtrace::__rust_begin_short_backtrace::h1555d669fee51da4
           4:  0x66b - <unknown>!std::rt::lang_start::{{closure}}::h8fec751e2998ce0e
           5: 0x8d32 - <unknown>!std::rt::lang_start_internal::h3159ffcdece8e084
           6:  0x61d - <unknown>!std::rt::lang_start::hca84d4aa64fc0faf
           7:  0x5ae - <unknown>!__original_main
           8:  0x3b7 - <unknown>!_start
       note: run with `WASMTIME_BACKTRACE_DETAILS=1` environment variable to display more information

Versions and Environment

Wasmtime version or commit: 0.26.0
Operating system: Ubuntu 20.04
Architecture: x86_64

Cargo.toml:

[package]
name = "wasi_test"
version = "0.1.0"
authors = [""]
edition = "2018"

[dependencies]
wasi = "0.10.2+wasi-snapshot-preview1"

[alexcrichton]

Wasmtime originally returned EINVAL for functions like this but as part of #2659 it was changed to a trap (what you see today). The rationale for this change is that it's more forwards-compatible with the predicted path of the interface types proposal. Currently AFAIK the precise behavior of what to do here with invalid ids is somewhat up in the air and is likely to be settled in the future as wasi migrates towards being entirely specified with interface types.

[enjhnsn2]

I see. Are there plans to rewrite the WASI spec somewhere down the line once interface types have been finalized? It would be good to know what WASI calls (or more generally, interface calls) we should expect to not return and which we can expect an error code from.

[alexcrichton]

I believe the general plan of action is to define WASI in terms of interface types, yes, although it won't necessarily be a complete rewrite but rather just specifying it via a different method.

[alexcrichton]

I'm going to close this as currently intended behavior, and I think this will naturally get clarified over time as WASI evolves.