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

David Herman dherman at mozilla.com
Fri Mar 22 22:34:05 PDT 2013


On 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?

Ken means that we should change the part of the specification that states the invariant about multiple representations of NaN being unobservable, because he wants typed arrays to be allowed to break that invariant.

I disagree with Ken.

> 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.
> 
> For interop, JS requires cross-browser (VM) NaN canonicalization to avoid observably different results on different browsers.

IMO this latter point is the most important: regardless of NaN-boxing, allowing different engines to non-deterministically produce one of several different bit patterns when writing a NaN into a typed array is under-specification and asking for portability bugs.

Not only that, but I believe any time a web API designer wants to break a long-standing invariant of JS, particularly one that is stated *explicitly* in ECMAScript, the onus is on them to argue that they have a right to break that invariant.

> Ergo, ES6 must specify normative handling of NaNs

Agreed.

Dave



More information about the es-discuss mailing list