data.length opcode

[SoniEx2]

we should have data.length opcode

(it should return 0 for dropped segments ofc)

[SoniEx2]

for context: memory.init (already) needs to know the data segment length so it can trap, but trapping isn't particularly useful for programs. a data.length would expose the length in an useful way (non-trapping).

a hypothetical single-pass compiler could use a data.length opcode for generated data segments, since data segments come after code segments. such data.length opcode also happens to be oddly convenient when hand-writing wasm/wat.

[rossberg]

A correctly compiled program should never mismatch the length of a segment. That would always be the symptom of a compiler bug, and non-trapping behaviour can't help with that.

I have written single-pass compilers targeting Wasm. They can just backpatch the constants, like they already have to do for various other values in the binary format. Moreover, in practice, data segments (e.g., for string literals) are typically synthesised during code emission itself in such a compiler (and emitted afterwards), so that I never even needed such backpatching.