Exact function imports #72
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Function references to imported functions must normally be inexact to preserve soundness in the case where the dynamic type of the imported function is a subtype of the import type. However, this difference between imported and declared functions harms modularity by making it possible for an instruction sequence to become invalid when a function it references is replaced with an import. To fix the modularity problem, introduce exact function imports that can be referenced exactly, just as defined functions can. Describe the problem and solution in the overview, and also update the interpreter to make references to normal imported functions inexact and to support exact function imports. Fixes #57.
|
Landing now to be able to use the tests downstream, but will happily address any feedback in a follow-up. |
rossberg
reviewed
Oct 28, 2025
| memories : memorytype list; | ||
| tables : tabletype list; | ||
| funcs : deftype list; | ||
| funcs : heaptype list; |
There was a problem hiding this comment.
I don't think this should be that general. If it's limited to (exact * deftype), the use sites become simpler, too.
Comment on lines
+417
to
418
| UseHT (Exact, Def (Lib.List32.nth dts y.it))) m.it.funcs in | ||
| ExternFuncT (Lib.List32.nth dts x.it) |
There was a problem hiding this comment.
Nit:
Suggested change
| UseHT (Exact, Def (Lib.List32.nth dts y.it))) m.it.funcs in | |
| ExternFuncT (Lib.List32.nth dts x.it) | |
| UseHT (Exact, Def (Lib.List32.nth dts y.it))) m.it.funcs | |
| in ExternFuncT (Lib.List32.nth dts x.it) |
|
|
||
| heaptypeuse : | ||
| | LPAR EXACT typeuse RPAR { fun c -> UseHT (Exact, Idx ($3 c).it) } | ||
| | typeuse { fun c -> UseHT (Inexact, Idx ($1 c).it) } |
There was a problem hiding this comment.
If the binary format syntactically allows arbitrary heaptypes, then the text format must, too, to stay equi-expressive. In particular, we should have tests for the invalid cases.
| error at | ||
| ("external function type should have defined type, but has " ^ | ||
| string_of_heaptype ht) | ||
|
|
tlively
added a commit
that referenced
this pull request
Oct 31, 2025
Address feedback from #72, including by using (exact, deftype) pairs instead of full heaptypes where possible in the interpreter. Update the overview accordingly. Also fix #74 by introducing a new externtype binary encoding for exact function imports rather than using an s33 in the existing function import variant.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Function references to imported functions must normally be inexact to
preserve soundness in the case where the dynamic type of the imported
function is a subtype of the import type. However, this difference
between imported and declared functions harms modularity by making it
possible for an instruction sequence to become invalid when a function
it references is replaced with an import.
To fix the modularity problem, introduce exact function imports that can
be referenced exactly, just as defined functions can.
Describe the problem and solution in the overview, and also update the
interpreter to make references to normal imported functions inexact and
to support exact function imports.
Fixes #57.