array_init_elem on dropped element segment #577
-
|
At the end of the wast script for array_init_elem there's these two tests, I'm unsure how the second test should pass if the first test drops the element it needs? ;; init_data/elem with dropped segments traps for non-zero length
(assert_return (invoke "drop_segs"))
(assert_return (invoke "array_init_elem" (i32.const 0) (i32.const 0) (i32.const 0))) |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 1 reply
-
|
Semantically, dropping a segment shrinks its size to zero, so a zero-length bulk op at offset 0 still succeeds (modulo null references). In this case, see the execution rule, steps 20-21. This behaviour is inherited from prior bulk ops like table.init and memory.init, though I cannot find corresponding tests for those with a quick search. The original motivation for this semantics is that the drop check becomes subsumed by the bounds check this way, so that an extra runtime check is avoided. This PR links to some of the history of bulk op boundary conditions. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the context, that all makes sense |
Beta Was this translation helpful? Give feedback.
Semantically, dropping a segment shrinks its size to zero, so a zero-length bulk op at offset 0 still succeeds (modulo null references). In this case, see the execution rule, steps 20-21.
This behaviour is inherited from prior bulk ops like table.init and memory.init, though I cannot find corresponding tests for those with a quick search.
The original motivation for this semantics is that the drop check becomes subsumed by the bounds check this way, so that an extra runtime check is avoided. This PR links to some of the history of bulk op boundary conditions.