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

David Herman dherman at mozilla.com
Fri Mar 22 22:38:54 PDT 2013


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

> On Mar 20, 2013, at 1:42 PM, Kevin Reid wrote:
> 
>> 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.
> 
> The buffer contents may have come form an external source or the buffer may be accessible for writes by an agent that is not part of the ES implementation.  The only thing that the ES implementation has absolute control over are its own reads from a buffer and the values it propagates from those reads.

I think you misunderstand what we mean here by write normalization. The goal here is not to ensure that specific bit patterns never appear in an ArrayBuffer. All possible bit patterns are and should be legal. Rather, the goal is to fully and deterministically specify that when the ES engine writes a NaN value into a Float32Array or Float64Array, a single canonical bit pattern is written into the ArrayBuffer. That is what ensures that it's impossible to distinguish different NaNs.

(As for reads, the only thing the spec needs to say is that all possible NaN patterns are read as the JS NaN value. The particular bit representation of the JS NaN value itself is an implementation-specific thing and doesn't need any particular speccing.)

Dave



More information about the es-discuss mailing list