Re: endianness (was: Observability of NaN distinctions — is this a concern?)
Mark S. Miller
erights at google.com
Thu Mar 28 13:42:33 PDT 2013
"prohibitively" depends on your tolerance. Modern machines can usually do
register-to-register byte order reversal rather speedily. Which big endian
machines do you have in mind?
On Wed, Mar 27, 2013 at 6:51 AM, Andreas Rossberg <rossberg at google.com>wrote:
> 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:
> > 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.
> es-discuss mailing list
> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss