On Tue, Mar 26, 2013 at 6:40 AM, Jussi Kalliokoski < [email protected]> wrote:
> > On Tue, Mar 26, 2013 at 4:16 AM, Oliver Hunt <[email protected]> wrote: > >> >> On Mar 26, 2013, at 2:35 PM, Allen Wirfs-Brock <[email protected]> >> wrote: >> >> > >> > On Mar 25, 2013, at 6:00 PM, Brendan Eich wrote: >> > >> >> Right, thanks for the reminder. It all comes back now, including the >> "how to write correct ending-independent typed array code" bit. >> > >> > Ok, so looping back to my earlier observation. It sounds like >> endian-ness can be observed by writing into an Float64Array element and >> then reading back from a Uint8Array that is backed by the same buffer. If >> there is agreement that this doesn't represent a significant >> interoperability hazard can we also agree that not doing NaN >> cannonicalization on writes to FloatXArray is an even less significant >> hazard and need not be mandated? >> > >> >> The reason I have pushed for NaN canonicalization is because it means >> that it allows (and in essence requires) that typedArray[n] = typedArray[n] >> can modify the bit value of typedArray[n]. >> >> An implementation _may_ be able to optimize the checks away in some >> cases, but most engines must perform checks on read unless they can prove >> that they were the original source of the value being read. >> >> Forcing canonicalization simply means that you are guaranteed that a >> certain behavior will occur, and so won't be bitten by some tests changing >> behavior that you may have seen during testing. I know Ken hates these >> sorts of things, but seriously in the absence of a real benchmark, that >> shows catastrophic performance degradation due to this, simply saying "this >> is extra work that will burn cpu cycles" without evidence is a waste of >> time. > > > I also disagree with you. > > >> Also there is absolutely no case in which abstract performance concerns >> should ever outweigh absolute security and correctness bugs. >> > > Could you elaborate on the security part? I doubt NaN distinctions can > really be of any significant use for fingerprinting, etc. > In SES, Alice says: var bob = confinedEval(bobSrc); var carol = confinedEval(carolSrc); // At this point, bob and carol should be unable to communicate with // each other, and are in fact completely isolated from each other // except that Alice holds a reference to both. // See <http://www.youtube.com/watch?v=w9hHHvhZ_HY> start // at about 44 minutes in. var shouldBeImmutable = Object.freeze(Object.create(null, {foo: {value: NaN}})); bob(shouldBeImmutable); carol(shouldBeImmutable); // Alice, by sharing this object with bob and carol, should still be able // to assume that they are isolated from each other Bob says: var FunnyNaN = // expression creating NaN with non-canonical internal rep // on this platform, perhaps created by doing funny typed array tricks if (wantToCommunicate1bitToCarol) { Object.defineProperty(shouldBeImmutable, 'foo', {value: FunnyNaN}); // The [[DefineProperty]] algorithm is allowed to overwrite shouldBeImmutable.foo // with FunnyNaN, since it passes the SameValue check. Carol says: if (isNaNFunny(shouldBeImmutable.foo)) { // where isNaNFunny uses typed array tricks to detect whether its argument has // a non-canonical rep on this this platform > > So far I've yet to come across any unexpected bugs caused by this, maybe > you have examples? NaN is usually a non-desired value so if you write a NaN > you probably had a bug in the first place. > > And about correctness, by definition NaN is a category, not a value; by > definition a NaN value is not the same as another NaN value. If you want to > canonicalize NaN, my suggestion is IEEE, not ES-discuss. ;) > You're confusing IEEE NaN with ES NaN. In ES, NaN is a value, not a bit pattern. In IEEE, NaN is a family of bit patterns. Type arrays make us face the issue of what IEEE NaN bit pattern an ES NaN value converts to. > > >> 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. > > Cheers, > Jussi > > >> --Oliver >> >> > Allen >> > >> > >> > >> > >> >> >> >> /be >> >> >> >> On Mar 25, 2013, at 4:33 PM, Kenneth Russell <[email protected]> wrote: >> >> >> >>> On Mon, Mar 25, 2013 at 4:23 PM, Brendan Eich <[email protected]> >> 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 >> >>> [email protected] >> >>> https://mail.mozilla.org/listinfo/es-discuss >> >> _______________________________________________ >> >> es-discuss mailing list >> >> [email protected] >> >> https://mail.mozilla.org/listinfo/es-discuss >> >> >> > >> > _______________________________________________ >> > es-discuss mailing list >> > [email protected] >> > https://mail.mozilla.org/listinfo/es-discuss >> >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss >> > > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > > -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
