Repository navigation
Spec interpreter/implementation discrepancy - a local with an invalid type and 0 count #2258
Description
My understanding of the definition of the code section in the online specification is that if an entry in locals has n=0 count that it's discarded and not represented in the AST of a module. This means that the corresponding local's type is parsed, but not validated. The reference interpreter implements this behavior and for this input:
(module binary
"\00asm\01\00\00\00"
"\01\04\01\60\00\00" ;; Type section: 1 type
"\03\02\01\00" ;; Function section: 1 function
"\0a\07" ;; code section, 7 bytes
"\01" ;; 1 function body
"\05" ;; body size, 5 bytes
"\01" ;; 1 locals entry
"\00" ;; count: 0
"\63\01" ;; type: (ref null 1) -- not a valid type index
"\0b" ;; end
)the spec interpreter passes. This same module (foo.wasm) does not validate in V8, SpiderMonkey, or Wasmtime, however. These engines all validate the local's type and reject the module saying that it's out-of-bounds.
I wanted to raise this as an issue to see if others have thoughts about this. I don't have a preference for how exactly to go here myself.
Activity
tlively commentedon Oct 2, 2026
With my implementer hat on, it makes much more sense to require a valid type here. Otherwise implementations would have to have special handling for decoding but not validating the type in these cases.
With my spec hat on, I don't see a good way to fix this, though.
rossberg commentedon Oct 2, 2026
The trade-off depends on the implementation. If validation is fused with decoding, like in many engines, a special case is avoided if this case is validated — though that special case might be really trivial. OTOH, for implementations that actually separate decoding/parsing and desugaring from validation — and that includes the spec itself — it is significantly harder to do the checking, since it would require extending the AST in rather artificial ways.
A third option would be to rule out this case by prohibiting zero-iteration local fragments. Though depending on the implementation details, that will be no less work than special casing for ignoring it?
bvisness commentedon Oct 2, 2026
Prohibiting zero-length runs of locals in the binary format would be very easy to implement (easier than adding a decode-but-don't-validate path for types) but I doubt it's web-compatible to do so. But I would love for that to be the case, and I've not checked if it shows up in the wild.
tlively commentedon Oct 2, 2026
I would strongly support prohibiting zero-length runs if that turns out to be web-compatible.