NaN payload doesn't propagate

RESOLVED INVALID

Status

()

RESOLVED INVALID
5 years ago
5 years ago

People

(Reporter: persona, Unassigned)

Tracking

30 Branch
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

5 years ago
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
(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.
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. ...
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.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → INVALID
(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.
(Reporter)

Comment 5

5 years ago
(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
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.
You need to log in before you can comment on or make changes to this bug.