Description
Each major browser passes the subtests Explicit value undefined for type {f32, f64, i64}
, which expect that an undefined value for value
for each of those types will become the value 0.
However, https://webassembly.github.io/spec/js-api/#dom-global-global step 5 says to call ToWebAssemblyValue if and only if the value is missing, not if it is undefined. Thus we should be expecting a different result for the test cases:
- https://github.com/web-platform-tests/wpt/blob/master/wasm/jsapi/global/constructor.any.js#L123
- https://github.com/web-platform-tests/wpt/blob/master/wasm/jsapi/global/constructor.any.js#L148
Given that every major implementation is treating missing the same as undefined, the spec should probably change.
Otherwise, we would expect
new WebAssembly.Global( { "value": "i64" }, undefined); --> throws TypeError
new WebAssembly.Global({ "value": "f32", undefined); --> NaN
new WebAssembly.Global({ "value": "f64, undefined); --> NaN
As ToWebAssemblyValue calls https://tc39.es/ecma262/multipage/abstract-operations.html#sec-tonumber and https://tc39.es/ecma262/multipage/abstract-operations.html#sec-tobigint64 directly. Neither of those AOs in ES normalize undefined to 0.