Current exact import s33 encoding is not backward compatible

[tlively]

A one-byte u32 can be inadvertently reinterpreted as a negative s33. We need to introduce a new bit to differentiate.

Thanks @titzer for the catch!

[rossberg]

Thinking about this some more: If we're ever gonna introduce memoryref and friends (which isn't implausible), then we'll face the exact same problem that exact function imports are solving, but with the other import kinds.

That suggests that a more forward-compatible design is to add an orthogonal exactness attribute to externtype as a whole, instead of having a special (and over-general) representation for functions specifically. In terms of binary format, that could simply be represented by a prefix opcode that is disjoint from any of the 5 existing import kind opcodes.

For now, we could make it invalid to use it on any other import type. Although in fact, there might even be optimisation potential in knowing that, say, an imported memory or table has exactly N pages / entries.

[tlively]

I would have a slight preference for just adding a new externtype variant using 0x05. We are not going to end up with so many kinds of imports that using an extra byte becomes necessary, even if we have to add exact versions of many of them. Also, even if we do get memory references or even table reference, it seems unlikely that we will ever get references to globals, tags, types, etc.

[rossberg]

it seems unlikely that we will ever get references to globals, tags, types, etc.

Not that unlikely actually, if we want to support module.new as the obvious generalisation of func.new (which would be a likely next step once we go down that route). I would opt for consistency and future-proofness here.

As for opcodes, how about we express it with a high bit or'able to the existing opcodes? There should be plenty of space in this byte to keep that forward-compatible. I'd suggest bit 6 (to also keep it open to a potential LEB reinterpretation).

[tlively]

Yep, using bit 6 sounds reasonable to me.