Conversation
This PR proposes uses section codes for known sections, which is more compact and easier to check in a decoder. It allows for user-defined sections that have string names to be encoded in the same manner as before. The scheme of using negative numbers proposed here also has the advantage of allowing a single decoder to accept the old (0xB) format and the new (0xC) format for the time being.
|
|
||
| The names section does not change execution semantics and a validation error in | ||
| this section does not cause validation for the whole module to fail and is | ||
| instead treated as if the section was absent. The expectation is that, when a |
There was a problem hiding this comment.
One idea we discussed was to have the names section be defined as a user-defined section. Then all the logic here (about how you can always ignore a names section -- that it doesn't have any semantic effect) could be hoisted and apply to all user-defined sections.
There was a problem hiding this comment.
Would that basically mean that we move the names section to the JS embedding spec?
There was a problem hiding this comment.
We could, although I think the names section makes sense more broadly. If we change the meaning from "user-defined" to "metadata" or "ignorable", then it wouldn't seem too out of place to have the core wasm spec define a metadata/ignorable section.
|
I screwed up the PR again by targeting master. Closing in favor of #739 |
|
Make that #740 |
3 participants
This PR proposes uses section codes for known sections, which is more compact and easier to check in a decoder. It allows for user-defined sections that have string names to be encoded in the same manner as before. The scheme of using negative numbers proposed here also has the advantage of allowing a single decoder to accept the old (0xB) format and the new (0xC) format for the time being.