`wasm_val_t` missmatch in Rust vs C causing errors in wasmi_c_api

[dimitris-aspetakis]

Hi! I was trying to use wasmi_c_api in one of my projects, and stumbled upon an error on v0.51.1, c_api/src/func.rs:203. I ended up chasing the error and found out through print-debugging that I was getting only half of the parameters I was trying to pass from the C side.

Upon closer inspection, this is what I gathered:

Here is the struct definition in C:

typedef struct wasm_val_t {
  wasm_valkind_t kind;
  union {
    int32_t i32;
    int64_t i64;
    float32_t f32;
    float64_t f64;
    struct wasm_ref_t* ref;
  } of;
} wasm_val_t;

And here in Rust:

pub struct wasm_val_t {
    /// The kind of the Wasm value.
    pub kind: wasm_valkind_t,
    /// The underlying data of the Wasm value classified by `kind`.
    pub of: wasm_val_union,
}

Importantly, wasm_val_union includes a u128 field, making it 16 bytes instead of the 8 in the C version:

pub union wasm_val_union {
    /// A Wasm 32-bit signed integer.
    pub i32: i32,
    /// A Wasm 64-bit signed integer.
    pub i64: i64,
    /// A Wasm 32-bit unsigned integer.
    pub u32: u32,
    /// A Wasm 64-bit unsigned integer.
    pub u64: u64,
    /// A Wasm 32-bit float.
    pub f32: f32,
    /// A Wasm 64-bit float.
    pub f64: f64,
    /// A Wasm `v128` value.
    pub v128: u128,
    /// A Wasm referenced object.
    pub ref_: *mut wasm_ref_t,
}

…and hence a difference in pointer arithmetic when iterating through wasm_val_vec_t objects.

As a total newcomer to the project, I don't think I have the capacity to track down exactly what's up with the missing value type in C, and which files I should touch — sorry.

[dimitris-aspetakis]

Actually, the solution might be changing c_api/include/wasm.h to simply add the v128 fields in:

enum wasm_valkind_enum {
  WASM_I32,
  WASM_I64,
  WASM_F32,
  WASM_F64,
  WASM_V128,
  WASM_EXTERNREF = 128,
  WASM_FUNCREF,
};

…and:

typedef struct wasm_val_t {
  wasm_valkind_t kind;
  union {
    int32_t i32;
    int64_t i64;
    float32_t f32;
    float64_t f64;
    __int128 v128;
    struct wasm_ref_t* ref;
  } of;
} wasm_val_t;

They might be unused by the upstream wasm.h, but at least this way they are consistent with the equivalent wasmi types (and it seems to work on my project).

[Robbepop]

@dimitris-aspetakis hi and thank you for the bug report and the findings so far!

Unfortunately the official wasm.h C-API is kinda unmaintained:
https://github.com/WebAssembly/wasm-c-api

Last update to the wasm.h header file was ~2 years ago and does not include support for Wasm simd proposal with its v128 type that is 128-bit. I am not even sure if it is ever planned for inclusion into wasm.h. I guess there simply are no plans since there seems that nobody has responsibility for it.

At the same time, Wasmi supports the Wasm simd proposal and thus the v128 type.
I wonder how other Wasmi C-API users are working around this issue. An example is the folks at Wasmer who are using Wasmi's C-API to have Wasmi as Wasmer backend. Maybe taking a look at their code might reveal another solution.

Changing the wasm.h is not a real solution that we should apply since it is kinda an official standard. I'd rather remove Wasm simd support from Wasmi's C-API implementation instead.

I will think about this a bit and come back to you.