Bug 282533 – Discrepancy in WebAssembly Memory64 Handling

• Status: RESOLVED
• Resolution: DUPLICATE
• Component: JavaScriptCore

A differential bug has been identified between the Webkit and SpiderMonkey (SPM) JavaScript engines when executing a WebAssembly module. The discrepancy arises from the handling of memory initialization parameters in WebAssembly with memory64 support enabled. The sample program executes without errors in Webkit but throws a `TypeError` in SpiderMonkey.

## Environment (Linux, x64)

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

        ```bash
        ./js  ./program.js
        ```

    - **Output**: Throws `TypeError: bad Memory initial size`.

## Test Case

The JavaScript code causing the differential behavior is as follows:

```js
const v1 = {"index":"i64","initial":"1","maximum":"32"};
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. 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)

[Radar WebKit Bug Importer]

<rdar://problem/139639855>

[Yusuke Suzuki]

*** This bug has been marked as a duplicate of bug 282532 ***