1040845 - NaN payload doesn't propagate

Status: RESOLVED INVALID

(Core :: JavaScript Engine, defect)

Description

[Fabian]

User Agent: Mozilla/5.0 (X11; Linux i686; rv:30.0) Gecko/20100101 Firefox/30.0 (Beta/Release)
Build ID: 20140611084758

Steps to reproduce:

u = new Uint8Array(8); 
f = new Float64Array(u.buffer); 
f[0] = NaN; 

u[0] = 1; // u[0] is part of the NaN payload
console.assert(isNaN(f[0]));

f[0] += 0;

console.log(u[0]);


Actual results:

It logs 0


Expected results:

It should preserve the NaN payload and log 1, according to https://en.wikipedia.org/wiki/NaN#Encoding

Comment 1

[Nicolas B. Pierron [:nbp]]

(In reply to persona from comment #0)
> Steps to reproduce:
> 
> u = new Uint8Array(8); 
> f = new Float64Array(u.buffer); 
> f[0] = NaN; 
> 
> u[0] = 1; // u[0] is part of the NaN payload
> console.assert(isNaN(f[0]));
> 
> f[0] += 0;

even with:
  f[0] = f[0];

> 
> console.log(u[0]);
> 
> 
> Actual results:
> 
> It logs 0
> 
> 
> Expected results:
> 
> It should preserve the NaN payload and log 1, according to
> https://en.wikipedia.org/wiki/NaN#Encoding

I am afraid that this cannot be handled without moving away from the NaN boxing.

Comment 2

[Tom S. (please needinfo tschuster)]

This behavior is covered by at least ES6:
24.1.1.6 8. a. & .b https://people.mozilla.org/~jorendorff/es6-draft.html#sec-setvalueinbuffer
... If value is NaN, rawValue may be set to any implementation choosen non-signaling NaN encoding. ...

Comment 3

[Tom S. (please needinfo tschuster)]

Ups: 24.1.1.6 8. a. & .b should be 24.1.1.6 7.a. for float32 and 24.1.1.6 8.a. for float64.

Comment 4

[Jeff Walden [:Waldo]]

(In reply to Fabian from comment #0)
> u[0] = 1; // u[0] is part of the NaN payload

This isn't guaranteed -- typed arrays are not specified as little or big endian specifically.  The closest you can get to acknowledgment of one or the other is by choosing a behavior using DataView methods.

So in conclusion, you're trying to invoke all sorts of not-well-defined behaviors here.  :-)  In general punning on typed array memory or its encoding is just not really a good idea.

Comment 5

[Fabian]

(In reply to Jeff Walden [:Waldo] (remove +bmo to email) from comment #4)
> (In reply to Fabian from comment #0)
> > u[0] = 1; // u[0] is part of the NaN payload
> 
> This isn't guaranteed -- typed arrays are not specified as little or big
> endian specifically.  The closest you can get to acknowledgment of one or
> the other is by choosing a behavior using DataView methods.

You're right, just assume that I modified one of the payload bits. 

I didn't find that paragraph in ES6, so it's fine that this getting closed. Would've been nice to stick to more strictly to IEEE 754 though.

Cheers

Comment 6

[Luke Wagner [:luke]]

Technically, we're not deviating from IEEE754; the loss of payload bits happens on the load which is a JS operation ((ArrayBuffer,offset) -> double) not defined by IEEE754.