Repository navigation
馃獧 Value text encoding ambiguities / quirks聽#718
Description
In looking at WAVE mapping to value defs (ref #639 (comment)) I found some quirks in the val rules:
char- Allows unescaped single quote
(value char '''), which is unambiguous in context but seems awkward to parse and confusing to read (especially if you're used to Python!). - Rejects unescaped double-quote (
'"'), which is slightly annoying to me, personally. 馃檪
- Allows unescaped single quote
- floats
f32is encoded ascore:f64which leaves rounding and overflow ambiguous, e.g.core:f64accepts1e99which will overflow anf32.f64canonrejectsnan:0xbut not-nan
- Handles in variants:
- Currently this would seem to be valid:
(value (option (future)) none), which is at least surprising if not actually wrong.
- Currently this would seem to be valid:
- Ints:
- Depending on how I squint it looks like
(value u64 -1)might be valid viacore:i64(wrapping tou64::MAX).
- Depending on how I squint it looks like
Separately: the bottom of the value definitions section describes value imports/exports but the Nope, I was looking in the wrong place.import/export defs are missing matching rules.
Activity
[-]Value 馃獧 text encoding ambiguities / quirks[/-][+]馃獧 Value text encoding ambiguities / quirks[/+]lukewagner commentedon Sep 9, 2026
Great points!
char: given that we're type-directed (towardschar-vs-string), I suppose the fix is to switch'<core:stringchar>'to"<core:stringchar>"(which makes sense;core:stringcharis meant to be used inside double-quotes in core wasm)f32canonand indicate that onlyfXXcanonmatchesfXX, and also rule out-nanvaltypeof avaluemay not contain handle or async types, before even considering whether thevalmatches the type.valuerequire thevalto match thevaltype". Since we have explicitly-signedu64/s64types at the component-level (unlikei64which is sign-agnostic), I suppose this justifies a break from core wasm (which allows(i64.const -1)) and so we should reject any integer outside of the natural range of{s,u}{8,16,32,64}that would otherwise require wrapping.import/export, unless I'm missing something, becausevalueis incomponentsort, it goes included inexternidx; it's also explicitly inexterntype, so I think it shows up as needed inimport/export, but let me know if I'm missing something.Happy if anyone wants to write these (or better) fixes in a PR; otherwise I can in a bit.