Skip to content

[spec] Ambiguous if opcodes after the 0xFC and 0xFD prefix have multiple valid encodings #1526

@MarkDerosier

Description

@MarkDerosier

https://webassembly.github.io/spec/core/appendix/index-instructions.html
lists the binary opcode of "i32.trunc_sat_f64_u" as 0xFC 0x03,

However, https://webassembly.github.io/spec/core/binary/instructions.html#numeric-instructions

lists "i32.trunc_sat_f64_u" as being encoded as 0xFC 3:u32.

The u32 is a link that goes to the LEB128 page of the spec, https://webassembly.github.io/spec/core/binary/values.html#binary-int ,
which I think notes that 'trailing zeros' are allowed in the encoding. It explicitly mentions that 0x03 and 0x83 0x00 are well formed encodings of the value 3.

Since unsigned integers have multiple encodings in LEB128, can't "i32.trunc_sat_f64_u" be encoded as 0xFC 0x03, and 0xFC 0x83 0x00 (among more encodings with trailing zeros)?

When the spec uses a an integer constant encoded as a LEB128 u32, does it intend the shortest encoding?
Similarly, select_t requires a vector of length 1, but there are multiple ways to encode 1.

In other places in the spec, such as the alignment field in memarg of memory instructions https://webassembly.github.io/spec/core/binary/instructions.html#memory-instructions, it would be useful to note that although the integers encoded are small, and there are only a few of them, it can still be longer than 1 byte due to trailing zeros encodings.

Personally I would prefer if there was only one way to encode said instructions as it would simplify my parser.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions