- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Wed, 28 Mar 2012 02:45:23 -0700
On 3/28/12 2:40 AM, Mark Callow wrote: > > > On 28/03/2012 18:33, Boris Zbarsky wrote: >> On 3/28/12 2:32 AM, Mark Callow wrote: >>> Then, if you are on a big-endian system an app will not be able to read >>> & write int, float, etc. into the int32Array, float32Array, etc. >> >> Why not? > 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... -Boris
Received on Wednesday, 28 March 2012 02:45:23 UTC