[whatwg] Endianness of typed arrays

[Roger Hågensen]

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.
>
> Regards
>
>      -Mark
>

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/