Binary encoding of string.new_wtf16_array and other array methods #66
Comments
hubot
pushed a commit
to v8/v8
that referenced
this issue
Mar 21, 2024
The four instructions that take i8/i16 arrays as inputs (i.e.
string.{new,encode}_wtf{8,16}_array) already considered these
to be nullable references, but optimistically rejected inputs
that were statically known to have type "none".
That doesn't match the general principle of allowing implicit
upcasting, so this patch relaxes the decoder to permit "none"
types at validation time (they'll trap at runtime, of course).
Context: WebAssembly/stringref#66
Bug: v8:12868
Change-Id: I813f8adc273c9e7ac23590ce239e47ce6117973b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5385442
Commit-Queue: Jakob Kummerow <[email protected]>
Reviewed-by: Matthias Liedtke <[email protected]>
Auto-Submit: Jakob Kummerow <[email protected]>
Commit-Queue: Matthias Liedtke <[email protected]>
Cr-Commit-Position: refs/heads/main@{#92942}
kripken
added a commit
to WebAssembly/binaryen
that referenced
this issue
Mar 21, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I noticed when fuzzing Binaryen vs V8 that V8 disallows an input of
(ref.null none)tostring.new_wtf16_array. That seems like it should be valid since it is a subtype of the array types. Talking to @tlively , he pointed out that other specs avoid this issue by having a type annotation in the binary format, which this spec seems to lack atm.(This is not urgent in any way, just filing this to remind us if/when activity on this spec resumes.)
The text was updated successfully, but these errors were encountered: