[whatwg] Endianness of typed arrays
rescator at emsai.net
Wed Mar 28 03:42:07 PDT 2012
On 2012-03-28 12:01, Mark Callow wrote:
> On 28/03/2012 18:45, Boris Zbarsky wrote:
>> On 3/28/12 2:40 AM, Mark Callow wrote:
>>> Because you said "JS-visible state (will) always be little-endian".
>> So? I don't see the problem, but maybe I'm missing something...
>> The proposal is that if you take an array buffer, treat it as a
>> Uint32Array, and write an integer of the form W | (X<< 8) | (Y<< 16)
>> | (Z<< 24) into it (where W, X, Y, Z are numbers in the range
>> [0,255]), then the byte pattern in the buffer ends up being WXYZ, no
>> matter what native endianness is.
>> Reading the first integer from the Uint32Array view of this data would
>> then return exactly the integer you started with...
> So now you are saying that only the JS-visible state of ArrayBuffer is
> little-endian. The JS-visible state of int32Array, etc. is in
> platform-endiannesss. I took your original statement to mean that all
> JS-visible state from TypedArrays is little-endian.
Getting rather messy this isn't it?
arrayBuffer should be native endianess (native as to the JS engine),
anything else does not logically make sense for me as a programmer.
xhr.responseType = 'arraybuffer' on the other hand is a bigger issue as
a client program (browser) could be little endian but the server could
be big endian.
So in this case it would make sense if xhr.responseType = 'arraybuffer'
and xhr.responseType = 'arraybuffer/le' was the same and
xhr.responseType = 'arraybuffer/be' was for big endian/network byte order.
Personally I think that arrayBuffer should be native, and that
xhr.responseType should be ambiguous, in other words let the
implementers make sure of the endianess.
A client can easily ask for a desired endianess from the server by using
normal arguments during the query, or possibly a xhr.responseEndian=''
property if that makes sense at all.
Roger "Rescator" Hågensen.
Freelancer - http://www.EmSai.net/
More information about the whatwg