On 27 March 2013 00:35, 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 missed that decision, and as much as I understand the reasoning, I think we need to work on it. There actually are (third-party) projects with ports of V8 and/or Chromium to big endian architectures. WebGL code should not break or become prohibitively expensive on them all of a sudden. /Andreas _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
