Bug 282532 – Discrepancy in Handling of BigInt in WebAssembly.Memory Initialization

• Status: NEW
• Component: JavaScriptCore

## Summary

A differential bug has been identified between the WebKit and SpiderMonkey JavaScript engines when initializing `WebAssembly.Memory` with `BigInt` values for the `initial` and `maximum` properties. WebKit throws a `TypeError`, indicating that `BigInt` cannot be converted to a number, whereas SpiderMonkey executes the code without errors.

## Environment (Linux, x64)

- WebKit Engine (Git a6d261838dcb9f9e9c7bad991bc3d880ae5358ee):
  Command:
  ```bash
  ./jsc ./test.js
  ```
  Output:
  ```
    Exception: TypeError: Conversion from 'BigInt' to 'number' is not allowed.
    Memory@[native code]
    global code@./test.js:2:34
  ```

- SpiderMonkey Engine (Git 4f44c14a73993e4490646bde47eacbf2b9d267aa):
  Command:
  ```bash
  ./js ./test.js
  ```
  Output: Executes without errors.

## Test Case

The JavaScript code causing the differential behavior is as follows:

```js
const v1 = {"index":"i64","initial":3n,"maximum":32n};
const v2 = new WebAssembly.Memory(v1);
```

## Expected Behavior
According to the WebAssembly memory64 proposal, the `limits` structure should support 64-bit addressing, allowing `initial` and `maximum` values to be specified as 64-bit integers. The `index` field should accept either `i32` or `i64`, indicating the address type. Therefore, all engines should be updated to support this proposal, rather than throwing errors when using `BigInt` values. The relevant parts of the proposal are:

```
<PLAINTEXT>
- Limits Structure:
  limits ::= {min u64, max u64?}

- Address Type:
  addrtype ::= i32 | i64

- Memory Type:
  memtype ::= addrtype limits
```

Reference: [WebAssembly memory64 proposal](https://github.com/WebAssembly/memory64/blob/main/proposals/memory64/Overview.md)

[Keith Miller]

We don't support the Memory64 proposal so this is expected until we do.

[Radar WebKit Bug Importer]

<rdar://problem/139639586>

[Yusuke Suzuki]

*** Bug 282533 has been marked as a duplicate of this bug. ***