On Tue, Mar 26, 2013 at 4:35 PM, David Herman <dher...@mozilla.com> wrote: > [breaking out a new thread since this is orthogonal to the NaN issue] > > While the Khronos spec never specified an endianness, TC39 agreed in May 2012 > to make the byte order explicitly little-endian in ES6: > > https://mail.mozilla.org/pipermail/es-discuss/2012-May/022834.html > > The de facto reality is that there are essentially no big-endian browsers for > developers to test on. Web content is being invited to introduce byte-order > dependencies. DataView is usually held up as the counter-argument, as if the > *existence* of a safe alternative API means no one will ever misuse the > unsafe one. Even if we don't take into account human nature, Murphy's Law, > and the fact that the web is the world's largest fuzz tester, a wholly > rational developer may often prefer not to use DataView because it's still > easier to read out bytes using [ ] notation instead of DataView methods. > > I myself -- possibly the one person in the world who cares most about this > issue! -- accidentally created a buggy app that wouldn't work on a big-endian > system, because I had no way of testing it: > > > https://github.com/dherman/float.js/commit/deb5bf2f5696ce29d9a6c1a6bf7c479a3784fd7b > > In summary: we already agreed on TC39 to close this loophole, it's the right > thing to do, and concern about potential performance issues on non-existent > browsers of non-existent systems should not trump portability and correctly > executing existing web content.
I am disappointed that this decision was made without input from both of the editors of the typed array spec and disagree with the statement that it is the right thing to do. -Ken > Dave > > This was not the plan of record on TC39. The plan was to fix the semantics as > little-endian. > > On Mar 25, 2013, at 6:00 PM, Brendan Eich <bren...@mozilla.com> wrote: > >> Right, thanks for the reminder. It all comes back now, including the "how to >> write correct ending-independent typed array code" bit. >> >> /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
