Closed
Bug 1040845
Opened 10 years ago
Closed 10 years ago
NaN payload doesn't propagate
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
RESOLVED
INVALID
People
(Reporter: persona, Unassigned)
Details
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•10 years ago
|
||
(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•10 years ago
|
||
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•10 years ago
|
||
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.
Updated•10 years ago
|
Status: UNCONFIRMED → RESOLVED
Closed: 10 years ago
Resolution: --- → INVALID
Comment 4•10 years ago
|
||
(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.
(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•10 years ago
|
||
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.
Description
•