You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
JavaScript should be able to inspect the declared limits on imported memories.
The Module.imports function returns information about the types of the module's imports, but it is missing some important information about memory limits. When memory is imported, the provided memory size is checked against the minimum size (and optional maximum size) declared by the module. However, there does not seem to be a way for JavaScript to learn about those limits.
The specification of Module.imports (linked below) defines what information is available to JavaScript about the module.
For memories, all it tells you is that the import has kind "memory".
The <dfn method for="Module">imports(|moduleObject|)</dfn> method, when invoked, performs the following steps:
1. Let |module| be |moduleObject|.\[[Module]].
1. Let |imports| be « ».
1. [=list/iterate|For each=] (|moduleName|, |name|, |type|) of [=module_imports=](|module|),
1. Let |kind| be the [=string value of the extern type=] |type|.
1. Let |obj| be «[ "{{ModuleImportDescriptor/module}}" → |moduleName|, "{{ModuleImportDescriptor/name}}" → |name|, "{{ModuleImportDescriptor/kind}}" → |kind| ]».
1. [=list/Append=] |obj| to |imports|.
1. Return |imports|.
</div>
(This algorithm has been mostly unchanged since at least #591, maybe earlier)
Adding a line after L567 like:
If |type| is of the form [=mem=] <var ignore>memtype</var>, add "{{ModuleImportDescriptor/limits}}" →
«[ "min" → type.min, "max" → type.max (if defined), "shared" → type.isShared ]» to |obj|.
would specify a way of communicating the details of the memory type to JavaScript. This may be useful for tables as well.
My use case is making a general-purpose WebAssembly worker, that you can pass a Module and it sets it up for you. To do the setup, in case there are imported memories, I have to figure out appropriate parameters to pass to the Memory constructor. Since the declared limits put hard constraints on the acceptable values, it would make my life much simpler to be able to read these from the Module itself, rather than having to track it out-of-band.
(Hi, I'm new here, apologies if this is the wrong place for this issue.)
The text was updated successfully, but these errors were encountered:
If I understand correctly, this is subsumed by the more general type reflection extension already proposed: with that, you can get the maximum size of a memory import as mem_import.type.maximum.
Oh wonderful, thank you very much. Yes, that proposal is exactly what I need, and this issue is essentially a duplicate of the linked WebAssembly/design#1046.
JavaScript should be able to inspect the declared limits on imported memories.
The
Module.imports
function returns information about the types of the module's imports, but it is missing some important information about memory limits. When memory is imported, the provided memory size is checked against the minimum size (and optional maximum size) declared by the module. However, there does not seem to be a way for JavaScript to learn about those limits.The specification of
Module.imports
(linked below) defines what information is available to JavaScript about the module.For memories, all it tells you is that the import has kind "memory".
spec/document/js-api/index.bs
Lines 542 to 548 in 2e629bc
spec/document/js-api/index.bs
Lines 561 to 570 in 2e629bc
Adding a line after L567 like:
would specify a way of communicating the details of the memory type to JavaScript. This may be useful for tables as well.
My use case is making a general-purpose WebAssembly worker, that you can pass a Module and it sets it up for you. To do the setup, in case there are imported memories, I have to figure out appropriate parameters to pass to the Memory constructor. Since the declared limits put hard constraints on the acceptable values, it would make my life much simpler to be able to read these from the Module itself, rather than having to track it out-of-band.
(Hi, I'm new here, apologies if this is the wrong place for this issue.)
The text was updated successfully, but these errors were encountered: