[spec] Describe backwards-compatibility and reserve 0xFF opcode #1900
Conversation
document/core/appendix/changes.rst
Outdated
| .. note:: | ||
| This allows previously illegal programs to become executable. | ||
|
|
||
| It also allows program executions that previously trapped to execute successfully. |
There was a problem hiding this comment.
I'm not sure about this point. Have we utilized this to extend semantics to date?
One reason to avoid that is that trapping is observable in an embedding context, and both Wasm programs and embedded environments can use trapping operations as security checks; i.e. a program won't continue past a divide by zero or and out-of-bounds memory access in an unanticipated state.
There was a problem hiding this comment.
I don't think we have used it yet, but I believe we have implicitly assumed that we could on a few occasions. I have recollections of design discussions where trapping was suggested as a conservative design choice for cases we don't know how to deal best with yet, e.g. due to possibly unknown future constraints. The answer of starting out with trapping for such cases implies that the trap could be lifted later.
We should definitely use this option rarely and carefully and only in cases where we previously documented that certain trapping cases might have legal behaviour in the future. But shutting out the possibility entirely would eliminate a valuable tool for incremental feature introduction.
Moreover, the same reasoning would apply to relaxing typing, just that it's affecting assumptions about static rather than dynamic failure.
There was a problem hiding this comment.
It seems useful to at least guarantee (if we can make such guarantees) that at least some traps will never be lifted, at the very least for the unreachable instruction.
Would it be feasible to include this sense of "cases where we previously documented that certain trapping cases might have legal behaviour in the future" in the text here, and limit the guarantee to that?
There was a problem hiding this comment.
Added a qualification along these lines.
document/core/appendix/changes.rst
Outdated
| a prior module may encounter new behaviours, | ||
| e.g., new forms of control flow or side effects when calling into a latter module. | ||
|
|
||
| In addition, the :ref:`instruction opcode <binary-instr>` :math:`\hex{FF}` is considered reserved for custom use and will never be allocated to represent an instruction or instruction prefix. |
There was a problem hiding this comment.
Should we say "future versions of the spec will not allocate 0xFF to a valid opcode"?
|
In the added text, "All syntactically well-formed and valid modules remain well-formed and valid...", the hyperlink on "well-formed" goes to the binary chapter, but the language could be read as applying to both formats. If it's intended that the text format will also be backwards-compatible, that would be great, but it would be a change from some post-1.0 cases (I think bulk memory) where compatibility was intentionally broken. Or if the text format isn't part of this, it could say something like "In the binary format, all syntactically well-formed..."? |
|
Do you have more details about the backward-incompatible text format change? I don't remember that. |
Sure, e.g. this was a valid module in Wasm 1.0 and became malformed after bulk-memory: (memory $x 0)
(data $x (i32.const 0))
(data $x (i32.const 0))(The bulk-memory proposal reassigned the id on a segment to refer to the segment itself, not the memory or table index, so this became a malformed duplicate use.) And, admittedly pre-1.0 (but still in a lot of online documentation), this was a valid module as late as 76d26bb but malformed after the renaming in #720 and #926: (table 0 anyfunc) |
|
Thanks, I hadn't known about that bulk memory change. Here's the issue about it, in case anyone wants to see the original discussion: WebAssembly/bulk-memory-operations#122. I hope that if we found a similar issue today, we would spend a little more time thinking about it 😅 I would be happy to document that we will maintain backward compatibility of the text format going forward. |
|
@keithw, I clarified that this applies to both formats, despite us having been a tiny bit more loose with the text format in the past. (Though I would almost tend to define away this one away as an early bug fix. :) ) @tlively, we do not formally define subtyping on module types as such, only on individual external types, from which it can be derived. But this formulation is merely intended to give an intuition. It inevitably is a bit informal, since it is relating different language versions, and the definition of types and subtyping itself can change (and has changed) between versions. |
document/core/appendix/changes.rst
Outdated
| 2. All non-:ref:`trapping <trap>` :ref:`executions <exec>` of a valid program retain their behaviour with an equivalent set of possible :ref:`results <syntax-result>` (or a non-empty subset). | ||
|
|
||
| .. note:: | ||
| This allows previously illegal programs to become executable. |
There was a problem hiding this comment.
What is meant by "illegal" here? Is there a more precise word we can use? "Invalid?"
There was a problem hiding this comment.
Malformed or invalid. I expanded it.
|
Merging for now, please open issue in case other concerns should come up. |
5 participants
Triggered by WebAssembly/design#1539, this spells out the intended backwards-compatibility constraints we assume of future Wasm versions. I believe this captures what was discussed in that context.