Ryan Hunt

This is the right place to ask for the JS-API limit to be increased. SpiderMonkey/Firefox shares the same restriction (taken from the JS-API) that you cannot ever grow a wasm...

> But as I see it, the request here is for that small use case. That is, this isn't for something like a game that we want everyone to run....

[SpiderMonkey bug](https://bugzilla.mozilla.org/show_bug.cgi?id=1908221) which should make it into [Fx130](https://whattrainisitnow.com/release/?version=130).

Can this be merged soon? I've gotten some reports that SpiderMonkey is not following the spec here because this isn't merged yet.

Yeah I like the idea behind this. The original implementation of #[cfg] was done quick and conservative. This would help make it easier to use for most cases.

> WebAssembly.Memory's maximum is not inspectable by user code; ArrayBuffers' maximum is inspectable With the [`js-types`](https://github.com/WebAssembly/js-types/blob/main/proposals/js-types/Overview.md) proposal a memoryObj.type() property would be added that exposes the original source maximum value...

> > There was quite a bit of discussion on this, but I can't find it because the memory64 repo was archived. > > I would hope that archiving the...

> An open question for me for that proposal is that upthread, I learned that there's a proposal to expose a memoryObj.type() property. If maxByteLength is Infinity, but memoryObj.type() reports...

> I think a simpler solution has been in plain sight all along: recompute `maxByteLength` from the max pages of the corresponding WebAssembly.Memory instance on access. In the web embedding,...

Ah, I think we might have a spec ambiguity here. Ben linked me to this issue: #1863 he filed a while ago. We read that line as part of a...