On Mar 25, 2013, at 2:40 PM, Brendan Eich wrote: > Kenneth Russell wrote: >>> > 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. > > That's at issue. By reading via an aliasing byte or wider integral-typed > array view, different results could be observed on two VMs for the exact same > code.
Note that the ES5.1 spec. says: "In some implementations, external code might be able to detect a difference between various Not-a-Number values, but such behaviour is implementation-dependent; to ECMAScript code, all NaN values are indistinguishable from each other." This language (with only minor editorial variation) has been in the spec. since ES1. It presumably means, among other things, that host functions might observe different NaN encodings being passed to them as arguments (ie, ES has never required NaN cannonicalization when passing number values to non-ES functions). Presumably such a function could write such a parameter value into a Float64Array element that is return to ES code where it is observed via a Uint8Array overlay. Has this ever caused a problem that anybody is aware of? BTW, isn't cannonicalization of endian-ness for both integers and floats a bigger interop issue than NaN cannonicalization? I know this was discussed in the past, but it doesn't seem to be covered in the latest Khronos spec. Was there ever a resolution as to whether or not TypedArray [[Set]] operations need to use a cannonical endian-ness? Allen _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
