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

Kevin Reid kpreid at
Wed Mar 20 12:34:53 PDT 2013

On Wed, Mar 20, 2013 at 12:10 PM, Allen Wirfs-Brock
<allen at>wrote:

> On Mar 20, 2013, at 10:09 AM, Kevin Reid wrote:
> > Depending on what you mean by “ECMAScript code”, this may be false given
> the Typed Arrays extension, which allows direct access to the bit-patterns
> of float values (the Typed Arrays spec permits, but does not require,
> replacing a NaN value with any other NaN value on read or write).
> This is not how it is specified in the ES6 spec. See steps 7.b
> & 8.b and steps 7.a & 8.a.  Normalization of NaN values is
> required on retrieval and permitted on stores form/to ArrayBuffers.

I see. I was reading the Khronos version and hadn't realized it was
included in ES6.

The ES spec. requirement (which isn't new to ES6) still applies.  If they
> expose observably different NaN values to any ECMAScript code they aren't
> conforming to the spec.

Then it seems to me that the wording of the spec, while not
self-contradictory, makes it unnecessarily unobvious how to correctly
implement it. Consider these two cases (which I think are exhaustive):

1. The implementation uses exactly one bit pattern for JS values which are
NaN. In this case, normalization is required on reads and is a no-op for

2. The implementation represents JS values which are NaN using arbitrary
NaN bit patterns (and SameValue considers them all equal). In this case,
normalization is unnecessary for reads and necessary for writes (else, as
my example code shows, the difference is observable which contradicts

Thus, normalization on write is either a no-op or necessary, so should be
mandatory, and normalization on read is unobservable in either case, so
need not be mandatory.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list