WebAssembly / esm-integration

ECMAScript module integration
https://webassembly.github.io/esm-integration/js-api/index.html#esm-integration
Other
378 stars 32 forks source link

Possible inconsistency in js<->wasm cycle example for value import #55

Closed takikawa closed 2 years ago

takikawa commented 3 years ago

In the JS<->Wasm import example from the examples page, there is a case for a value import in which the Wasm module imports a non-WebAssembly.Global value from JS as a Wasm global.

This case says it should result in "0 if a const import and not in TDZ, otherwise Error", but it seems like it should always be an error to be consistent with the JS API semantics for normal Wasm imports.

I think the 0 there comes from the fact that the JS binding has value undefined, which converts to 0 via ToInt32. But the Wasm JS API spec only does the ToWebAssemblyValue conversion on value imports when it satisfies the check "If Type(v) is Number or BigInt," (see 3.5.1 in https://webassembly.github.io/esm-integration/js-api/index.html#read-the-imports)

Example:

function module(bytes, valid = true) {
  let buffer = new ArrayBuffer(bytes.length);
  let view = new Uint8Array(buffer);
  for (let i = 0; i < bytes.length; ++i) {
    view[i] = bytes.charCodeAt(i);
  }
  return new WebAssembly.Module(buffer);
}

// throws LinkError
// The Wasm is (module (global (export "g") (import "m" "g") i32))
const inst = new WebAssembly.Instance(module("\x00\x61\x73\x6d\x01\x00\x00\x00\x02\x08\x01\x01\x6d\x01\x67\x03\x7f\x00\x07\x05\x01\x01\x67\x03\x00"),
                                      { m: { g: undefined } });