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

Kevin Reid kpreid at google.com
Wed Mar 20 13:42:14 PDT 2013


On Wed, Mar 20, 2013 at 12:56 PM, Allen Wirfs-Brock
<allen at wirfs-brock.com>wrote:

>
> If you're specifically talking about reading/writing TypedArray elements
> (really ArrayBuffers) you have to take into account the possibility that
> you can have different types overlaying the same buffer storage.
>

Yes, that was my original example.


>   Hence a NaN bit pattern might be written as 2 Uint32 values and then
> retrieved as a Float64 value.  In that case, there is no Float64 write to
> perform the normalization so it must be done on all reads. Such
> normalization is especially important if object pointers are represented
> using  NaN-boxing.
>

That normalization on read is is my case 1 above — it is necessary _for
that implementation_. A conformant implementation could use a different
strategy which does not normalize on Float64 read, and this would be
unobservable, so the spec should not bother to specify it.

However, lack of normalization on Float64 write _is_ potentially observable
(if the implementation does not normalize all NaNs from all sources).
Therefore, I argue, the spec should specify that normalization happens on
write; and it happens that an implementation can omit that as an explicit
step, with no observable difference, if and only if its representation of
NaN in JS values (from all possible sources, not just typed arrays) is
normalized.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130320/bf5f82fc/attachment.html>


More information about the es-discuss mailing list