Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Version 1? #1513

Open
pannous opened this issue Mar 28, 2024 · 5 comments
Open

Version 1? #1513

pannous opened this issue Mar 28, 2024 · 5 comments

Comments

@pannous
Copy link

pannous commented Mar 28, 2024

Many tools are now creating wasm files with magic number 1 in the first bytes, even though they are not compatible with wasm version 1, as they contain extra features. How did this malpractice become so widespread and what are measures to eliminate this urgent problem?

@tlively
Copy link
Member

tlively commented Mar 28, 2024

This is working as intended. The version number in the binary format is there in case we ever need to introduce a new version of the binary format that would require implementations to use a completely different parser implementation. Adding new features is kind of a breaking change because old parsers cannot parse modules that use newer features, but the feature version in the binary format is not meant to address that kind of change. In other words, the binary format version is not the same as the WebAssembly spec version.

From the spec itself:

The version of the WebAssembly binary format may increase in the future if backward-incompatible changes have to be made to the format. However, such changes are expected to occur very infrequently, if ever. The binary format is intended to be forward-compatible, such that future extensions can be made without incrementing its version.

@kmiller68
Copy link
Contributor

Shouldn’t that be backwards-compatible not forwards? I would assume forwards compatibility is when you can run new code on an old system. Which may be the source of confusion leading to this issue.

@tlively
Copy link
Member

tlively commented Mar 28, 2024

Yeah, we've discussed adding mechanism to allow real forward compatibility like that (e.g. conditional sections and feature detection) but they never got very far.

@kmiller68
Copy link
Contributor

I guess I meant it's a bit weird that the spec says "The binary format is intended to be forward-compatible, such that future extensions can be made without incrementing its version." which is not true from the wikipedia definition of forwards compatibility. "Forward compatibility or upward compatibility is a design characteristic that allows a system to accept input intended for a later version of itself." e.g. I can't use a WASM binary compiled with GC with an old browser without GC. Maybe it shouldn't talk about forward compatibility at all until such a mechanism is in the standard?

@tlively
Copy link
Member

tlively commented Mar 29, 2024

I agree. Rewording that spec note would be reasonable.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants