[spec] Normative: Remove ahead of time bounds checks from instantiation #820
Conversation
document/core/exec/modules.rst
Outdated
| @@ -613,10 +613,6 @@ It is up to the :ref:`embedder <embedder>` to define how such conditions are rep | |||
|
|
|||
| h. Let :math:`\X{eend}_i` be :math:`\X{eo}_i` plus the length of :math:`\elem_i.\EINIT`. | |||
There was a problem hiding this comment.
Nit: Maybe move this down to where it is actually used first now.
document/core/exec/modules.rst
Outdated
| @@ -635,17 +631,17 @@ It is up to the :ref:`embedder <embedder>` to define how such conditions are rep | |||
|
|
|||
| h. Let :math:`\X{dend}_i` be :math:`\X{do}_i` plus the length of :math:`\data_i.\DINIT`. | |||
|
12th is probably too soon, so maybe the meeting on the 26th? |
|
Sounds good. I won't be able to attend the 12th anyway. |
|
Added future meeting item here |
|
I'll keep this open until at least the next CG, but it seems the consensus from this week's meeting was that we should go with this solution, but bundle it with the bulk memory proposal. |
|
Is it practical to further relax this to do the bounds check for each byte/element copied? As noted in the original issue, an extension that adds shrinking memories/tables or page protection makes it impractical to ensure the copy will be all-or-nothing. |
|
After @jfbastien pointed this out, we concluded in WebAssembly/threads#96 that we would need to do basically as you propose. The current idea is that segment initialization and bulk operations will (observably) perform writes from low to high addresses in order at byte/element granularity until oob. I think this still needs to be fleshed out in the proposal repo, however. |
|
Closing, as this behavior is moved to the bulk memory proposal. |
See WebAssembly/threads#94 for background. The current specification does not extend neatly to the multi-threaded case.
This PR corresponds to potential solution 2, which received a broadly positive initial response, and would allow data initialisers to be used with shared memories.
I choose to make the per-initialiser bounds checks result in a Trap/RuntimeError rather than a Fail/LinkError, since this makes the behaviour indistinguishable from using bulk memory operations in the start function, and I believe users might expect LinkError to guarantee no side effects have taken place.