On Fri, Mar 22, 2013 at 7:47 PM, Brendan Eich <[email protected]> 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 _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
