Re: Observability of NaN distinctions — is this a concern?

Kenneth Russell kbr at google.com
Mon Mar 25 11:33:24 PDT 2013


On Fri, Mar 22, 2013 at 7:47 PM, Brendan Eich <brendan at mozilla.com> wrote:
> Kenneth Russell wrote:
>>
>> I hope that the ES6 integration of typed arrays will not require
>> normalization of NaNs on write, even if other specification changes
>> need to be made to avoid requiring it.
>
>
> What other specification changes?
>
> JITs use nan-boxing
> (http://wingolog.org/archives/2011/05/18/value-representation-in-javascript-implementations).
> If a typed array user could forge a nan-boxed value, they could pwn the
> JITting VM.

As has been pointed out before, such JavaScript implementations must
already normalize NaN values read from Float32Array and Float64Array.
This is sufficient to protect against forging of NaN-boxed values.


> For interop, JS requires cross-browser (VM) NaN canonicalization to avoid
> observably different results on different browsers.

As long as NaN values loaded from Float32Array and Float64Array obey
ES6's semantics, such as returning true from isNaN(), then it should
not matter whether the ES6 implementation happens to support multiple
bit patterns for NaN. NaNs are an error condition and corner case in
floating-point algorithms, and it is important not to negatively
impact the performance of the common case in order to achieve
absolutely precise semantics for this error case.

-Ken


> Ergo, ES6 must specify normative handling of NaNs
>
> /be


More information about the es-discuss mailing list