This repository has been archived by the owner on Nov 3, 2021. It is now read-only.
Meaning of out-of-range zero-length 'memory.fill' / 'memory.copy' #11
Comments
|
I would advocate for the same behavior as for data segments. There was pretty extensive discussion here: WebAssembly/design#897 |
|
@jfbastien, seconded. That would imply that these instructions trap when either source or destination end offset is out of bounds. That would match @julian-seward1's preference as well. |
moz-v2v-gh
pushed a commit
to mozilla/gecko-dev
that referenced
this issue
May 7, 2018
…ory.copy. r=lth. This patch adds an initial implementation, along with test cases, for the memory.fill and memory.copy instructions that form part of the bulk-memory-operations proposal at https://github.com/WebAssembly/bulk-memory-operations/blob/master/proposals/bulk-memory-operations/Overview.md. This covers code generation for the baseline and optimising compilers, as well as supporting infrastructure for conversion to/from binary and text representations. The implementation is simple in the sense that -- for both compilers -- it is done by a call to a helper function, which eventually devolves to a call to memset/memmove respectively. Per subsequent clarification requests: * WebAssembly/bulk-memory-operations#8 The arguments to these instructions are all interpreted as unsigned 32 bit ints. * WebAssembly/bulk-memory-operations#11 Zero length fills/copies that have starting point offsets out of bounds trap rather than are treated as no-ops. --HG-- extra : rebase_source : 79c74cbe467905f03b796428ee80b643c105ca72
binji
added a commit
that referenced
this issue
Jan 23, 2019
`memory.init`, `memory.copy`, `memory.fill`, `table.init`, and `table.copy` should all fail if their ranges are out-of-bounds, even if the count is zero, similar to for active segments. See the discussions here: WebAssembly/design#897, #11.
binji
added a commit
that referenced
this issue
Jan 24, 2019
`memory.init`, `memory.copy`, `memory.fill`, `table.init`, and `table.copy` should all fail if their ranges are out-of-bounds, even if the count is zero, similar to for active segments. See the discussions here: WebAssembly/design#897, #11.
brn
pushed a commit
to brn/v8
that referenced
this issue
Jan 30, 2019
The spec wasn't clear (or I misunderstood). As per (WebAssembly/bulk-memory-operations#11), zero-count table operations are also out of bounds. [email protected] [email protected] BUG=v8:7747 Change-Id: Iac689b93a040eb6eb06975bc2ba0facb85d24756 Reviewed-on: https://chromium-review.googlesource.com/c/1436022 Reviewed-by: Michael Starzinger <[email protected]> Commit-Queue: Ben Titzer <[email protected]> Cr-Commit-Position: refs/heads/master@{#59121}
gecko-dev-updater
pushed a commit
to marco-c/gecko-dev-comments-removed
that referenced
this issue
Oct 3, 2019
…ory.copy. r=lth. This patch adds an initial implementation, along with test cases, for the memory.fill and memory.copy instructions that form part of the bulk-memory-operations proposal at https://github.com/WebAssembly/bulk-memory-operations/blob/master/proposals/bulk-memory-operations/Overview.md. This covers code generation for the baseline and optimising compilers, as well as supporting infrastructure for conversion to/from binary and text representations. The implementation is simple in the sense that -- for both compilers -- it is done by a call to a helper function, which eventually devolves to a call to memset/memmove respectively. Per subsequent clarification requests: * WebAssembly/bulk-memory-operations#8 The arguments to these instructions are all interpreted as unsigned 32 bit ints. * WebAssembly/bulk-memory-operations#11 Zero length fills/copies that have starting point offsets out of bounds trap rather than are treated as no-ops. UltraBlame original commit: bb402086c764108a03d90a8b29256dce4eee4cba
gecko-dev-updater
pushed a commit
to marco-c/gecko-dev-wordified
that referenced
this issue
Oct 3, 2019
…ory.copy. r=lth. This patch adds an initial implementation, along with test cases, for the memory.fill and memory.copy instructions that form part of the bulk-memory-operations proposal at https://github.com/WebAssembly/bulk-memory-operations/blob/master/proposals/bulk-memory-operations/Overview.md. This covers code generation for the baseline and optimising compilers, as well as supporting infrastructure for conversion to/from binary and text representations. The implementation is simple in the sense that -- for both compilers -- it is done by a call to a helper function, which eventually devolves to a call to memset/memmove respectively. Per subsequent clarification requests: * WebAssembly/bulk-memory-operations#8 The arguments to these instructions are all interpreted as unsigned 32 bit ints. * WebAssembly/bulk-memory-operations#11 Zero length fills/copies that have starting point offsets out of bounds trap rather than are treated as no-ops. UltraBlame original commit: bb402086c764108a03d90a8b29256dce4eee4cba
gecko-dev-updater
pushed a commit
to marco-c/gecko-dev-wordified-and-comments-removed
that referenced
this issue
Oct 3, 2019
…ory.copy. r=lth. This patch adds an initial implementation, along with test cases, for the memory.fill and memory.copy instructions that form part of the bulk-memory-operations proposal at https://github.com/WebAssembly/bulk-memory-operations/blob/master/proposals/bulk-memory-operations/Overview.md. This covers code generation for the baseline and optimising compilers, as well as supporting infrastructure for conversion to/from binary and text representations. The implementation is simple in the sense that -- for both compilers -- it is done by a call to a helper function, which eventually devolves to a call to memset/memmove respectively. Per subsequent clarification requests: * WebAssembly/bulk-memory-operations#8 The arguments to these instructions are all interpreted as unsigned 32 bit ints. * WebAssembly/bulk-memory-operations#11 Zero length fills/copies that have starting point offsets out of bounds trap rather than are treated as no-ops. UltraBlame original commit: bb402086c764108a03d90a8b29256dce4eee4cba
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
What should happen when memory.fill/.copy are requested to process zero bytes, but the destination and/or source offsets are out of range? Should there be an out-of-range exception? Or should the operations be no-ops?
I'd vote for throwing an exception, on safety/correctness grounds.
The text was updated successfully, but these errors were encountered: