Drop 64-bit types from the signatures

[zeux]

I will not be surprised the ship has sailed on this one, but I'd like to file this issue regardless.

As it stands today, WASI is incompatible with Wasm MVP because multiple functions use 64-bit types in function signatures without using pointers to wrap them. This is true of path_open, fd_seek and possibly some others.

This is problematic because Wasm MVP doesn't define a mapping between int64 and any JS types, which means that it's impossible to load a WASI Wasm binary into a browser.

This issue can be worked around, either by a i64 lowering pass, or by dropping these specific WASI calls and replacing it with other calls, making the Wasm binary non-WASI compliant. None of these are good options - lowering requires a heavy transformer framework with JS-side Wasm parsers, and working around the ABI makes Wasm binaries application-specific.

Now, in theory this problem is solved by BigInt <-> i64 mapping, but in practice this is not enabled by default in Node.js (requires an experimental command-line flag!), and doesn't seem to be available in Safari based on https://www.chromestatus.com/feature/5648655109324800.

[devsnek]

Duplicate of #54

Also when nodejs/node#35415 lands, Node will support i64<->BigInt.

[zeux]

I’m concerned about Safari support for this but based on the above like I suspected the ship has sailed. Thanks.

[caspervonb]

Now, in theory this problem is solved by BigInt <-> i64 mapping, but in practice this is not enabled by default in Node.js (requires an experimental command-line flag!), and doesn't seem to be available in Safari based on

WebAssembly BigInt integration is enabled by default in Deno, we flipped the switch early to support WASI but its enabled by default in v8 now since v8.5 so I suspect Node will have it enabled by in their next v8 bump.

Safari will eventually have to follow eventually but a wasm-opt lowering pass can be used in the meantime.