W3C home > Mailing lists > Public > whatwg@whatwg.org > March 2012

[whatwg] Endianness of typed arrays

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Wed, 28 Mar 2012 01:47:57 -0700
Message-ID: <4F72D03D.4020002@mit.edu>
On 3/28/12 1:14 AM, Charles Pritchard wrote:
> Most developers work with multiple programming languages. They read
> manuals, they read blogs, they try things out, and then they often code
> more in other languages than in JS.

Are you sure this is true for most developers creating web content?

> But those that endeavor to make quality games and demos do try to
> consume as much as they can.

See, at this point people are using typed arrays for a lot more than 
"games and demos".  I will make no judgement about "quality".

> I don't want to be in this kind of conversation with you nor Robert.

I honestly don't want to be in this conversation either, all that much. 
  But I think the current state of the typed array specification is 
actively bad for the web, and I sort of care about that sort of thing.

> Your statements of fact are fine.

OK.

> Your claim that "developers ... just do whatever" is toxic.

My claim is that developers do "what works", not "whatever".

And I can totally understand where they're coming from, by the way. 
They just want something to work.  They read several tutorials on the 
subject, they write the code, they test it in a browser, if they're 
conscientious they test it in several browsers.  Everything seems to be 
working fine, so they deploy.  At no point in that does reading the spec 
per se enter the picture.  The spec is typically written to target 
_implementors_, not developers, and it shows.  It's near impossible to 
get useful information out of it, as a developer.  This is true for 
specs in general, not just the typed array spec.

This is not limited to web developers, by the way.  How many C or C++ 
developers really read the C or C++ spec and then write code that 
follows the spec to the letter?  Precious few, in my experience, for the 
same reasons: the specs are targeted at compiler implementors, not 
developers.  I say this as a C/C++ developer but not a compiler 
implementor.  ;) And even ones who do read the spec then proceed to 
write code that doesn't follow the spec, and feel that this is fine 
because their core works OK on their target architectures.  As a result, 
finding a C program that doesn't rely on undefined behavior takes some 
doing.  It's the same dynamic at work: code is written, compiled with a 
particular compiler (or small set of compilers) for a particular 
architecture or small set of architectures, tested, then shipped.  The 
number of C programs assuming that there are 8 bits in an unsigned char 
is ... large, for example.  Likewise for the number of C programs 
assuming that (int)0xFFFFFFFF == -1.  Or that INT_MAX+1==INT_MIN.  Or 
that you can cast between function pointers, or cast a function pointer 
to void*, or any of a huge number of other things.  And the world still 
works, more or less ok.

What I don't understand is why you think that keeping this reality in 
mind is "toxic".

> When you or Robert disparage developers as a class, that is harmful.

I'm not disparaging developers; I'm saying that the way things are right 
now developers are assuming typed arrays are little-endian and that this 
makes total sense.  If I were writing code using typed arays, I'd 
probably do the same.  The cost-benefit tradeoff to those developers is 
that the cost of trying to support big-endian typed arrays is decidedly 
nonzero while the benefit is very close to zero, if not identically 
zero.  So they don't support the big-endian stuff, just like Gecko 
doesn't work correctly on hardware with 32-bit unsigned chars or 
hardware with 16-bit ints.

If you think these developers are somehow being "bad" by making this 
cost-benefit analysis, then _you_ are doing the disparaging.  I think 
they're just being rational.  And if we (members of this mailing list, 
the WebGL working group, tech evangelists, whatever) started berating 
them for not testing endianness, which is what you seem to be proposing, 
they would rightfully tell us that we're full of it.  Several of the 
presenters at SXSW explicitly told me that when I mentioned the issue to 
them privately after their presentations: they were quite cognizant of 
the endianness issue, and had no problem whatsoever with assuming 
little-endian behavior.

-Boris
Received on Wednesday, 28 March 2012 01:47:57 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:40 UTC