Re: endianness (was: Observability of NaN distinctions — is this a concern?)

Andreas Rossberg rossberg at google.com
Wed Mar 27 06:51:34 PDT 2013


On 27 March 2013 00:35, David Herman <dherman at 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


More information about the es-discuss mailing list