On Mar 26, 2013, at 9:12 PM, Jussi Kalliokoski <jussi.kallioko...@gmail.com> wrote:
> That's just because ES has had no notion of bits for floating points before. > Other than that, ES NaN works like IEEE NaN, e.g. > > 0/0 === NaN // false > isNaN(0/0) // true That's true in any language - comparing to NaN is almost always defined explicitly as producing false. You're not looking at bit patterns, here so conflating NaN compares with bit values is kind of pointless. > > > > > > We need to stop raising "this causes performance problems" type issues > without a concrete example of that problem. I remember having to work very > hard to stop WebGL from being a gaping security hole in the first place and > it's disappointing to see these same issues being re-raised in a different > forum to try and get them bypassed here. > > Before saying security hole, please elaborate. Also, when it comes to > standards, I think change should be justified with data, rather than the > other way around. > > Done. > > You'll have to do better than that. ;) Ok, I'll try to go over this again, because for whatever reason it doesn't appear to stick: If you have a double-typed array, and access a member: typedArray[0] Then in ES it is a double that can be one of these values: +Infinitity, -Infinity, NaN, or a discrete value representable in IEEE double spec. There are no signaling NaNs, nor is there any exposure of what the underlying bit pattern of the NaN is. So the runtime loads this double, and then stores it somewhere, anywhere, it doesn't matter where, eg. var tmp = typedArray[0]; Now you store it: typedArray[whatever] = tmp; The specification must allow a bitwise comparison of typedArray[whatever] to typedArray[0] to return false, as it is not possible for any NaN-boxing engine to maintain the bit equality that you would otherwise desire, as that would be trivially exploitable. When I say security and correctness i mean it in the "can't be remotely pwned" sense. Given that we can't guarantee that the bit pattern will remain unchanged the spec should mandate normalizing to the non-signalling NaN. --Oliver > > Cheers, > Jussi > > > > > Cheers, > Jussi > > > --Oliver > > > Allen > > > > > > > > > >> > >> /be > >> > >> On Mar 25, 2013, at 4:33 PM, Kenneth Russell <k...@google.com> wrote: > >> > >>> On Mon, Mar 25, 2013 at 4:23 PM, Brendan Eich <bren...@mozilla.com> wrote: > >>>> Allen Wirfs-Brock wrote: > >>>>> > >>>>> On Mar 25, 2013, at 4:05 PM, Brendan Eich wrote: > >>>>> > >>>>>> Allen Wirfs-Brock wrote: > >>>>>>> > >>>>>>> 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? > >>>>>> > >>>>>> Search for "byte order" at > >>>>>> https://www.khronos.org/registry/typedarray/specs/latest/. > >>>>> > >>>>> > >>>>> I had already search for "endian" with similar results. It says that > >>>>> the > >>>>> default for DataViews gets/sets that do not specify a byte order is > >>>>> big-endean. It doesn't say anything (that I can find) about such > >>>>> accesses on > >>>>> TypedArray gets/sets. > >>>> > >>>> > >>>> Oh, odd -- I recall that it used to say little-endian. Typed arrays are > >>>> LE > >>>> to match dominant architectures, while DataViews are BE to match packed > >>>> serialization use-cases. > >>>> > >>>> Ken, did something get edited out? > >>> > >>> No. The typed array views (everything except DataView) have used the > >>> host machine's endianness from day one by design -- although the typed > >>> array spec does not state this explicitly. If desired, text can be > >>> added to the specification to this effect. Any change in this behavior > >>> will destroy the performance of APIs like WebGL and Web Audio on > >>> big-endian architectures. > >>> > >>> Correctly written code works identically on big-endian and > >>> little-endian architectures. See > >>> http://www.html5rocks.com/en/tutorials/webgl/typed_arrays/ for a > >>> detailed description of the usage of the APIs. > >>> > >>> DataView, which is designed for input/output, operates on data with a > >>> specified endianness. > >>> > >>> -Ken > >>> _______________________________________________ > >>> es-discuss mailing list > >>> es-discuss@mozilla.org > >>> https://mail.mozilla.org/listinfo/es-discuss > >> _______________________________________________ > >> es-discuss mailing list > >> es-discuss@mozilla.org > >> https://mail.mozilla.org/listinfo/es-discuss > >> > > > > _______________________________________________ > > es-discuss mailing list > > es-discuss@mozilla.org > > https://mail.mozilla.org/listinfo/es-discuss > > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > > > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > > > > > -- > Cheers, > --MarkM >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
