Re: Observability of NaN distinctions — is this a concern?

Kenneth Russell kbr at
Mon Mar 25 16:33:18 PDT 2013

On Mon, Mar 25, 2013 at 4:23 PM, Brendan Eich <brendan at> wrote:
> Allen Wirfs-Brock wrote:
>> On Mar 25, 2013, at 4:05 PM, Brendan Eich wrote:
>>> Allen Wirfs-Brock wrote:
>>>> BTW, isn't cannonicalization of endian-ness for both integers and floats
>>>> a bigger interop issue than NaN cannonicalization?  I know this was
>>>> discussed in the past, but it doesn't seem to be covered in the latest
>>>> Khronos spec.  Was there ever a resolution as to whether or not TypedArray
>>>> [[Set]] operations need to use a cannonical endian-ness?
>>> Search for "byte order" at
>> I had already search for "endian" with similar results.  It says that the
>> default for DataViews gets/sets that do not specify a byte order is
>> big-endean. It doesn't say anything (that I can find) about such accesses on
>> TypedArray gets/sets.
> Oh, odd -- I recall that it used to say little-endian. Typed arrays are LE
> to match dominant architectures, while DataViews are BE to match packed
> serialization use-cases.
> Ken, did something get edited out?

No. The typed array views (everything except DataView) have used the
host machine's endianness from day one by design -- although the typed
array spec does not state this explicitly. If desired, text can be
added to the specification to this effect. Any change in this behavior
will destroy the performance of APIs like WebGL and Web Audio on
big-endian architectures.

Correctly written code works identically on big-endian and
little-endian architectures. See for a
detailed description of the usage of the APIs.

DataView, which is designed for input/output, operates on data with a
specified endianness.


More information about the es-discuss mailing list