Bug 53598

Summary: [V8] Incorrect behavior of NaNs in DataView (setting values, bit patterns)
Product: WebKit Reporter: Joshua Bell <inexorabletash>
Component: WebGLAssignee: Kenneth Russell <kbr>
Status: RESOLVED INVALID    
Severity: Minor CC: enne, jianli, kbr, zmo
Priority: P3    
Version: 528+ (Nightly build)   
Hardware: PC   
OS: Windows 7   

Joshua Bell
Reported 2011-02-02 08:54:06 PST
A handful of cases with NaNs in Typed Arrays. var f32 = new Float32Array(1); // Expected: f32[0] = NaN f32[0] >>> NaN // Unexpected: f32.set([NaN]) f32[0] >>> 0 // (expected NaN) // Unexpected: f32 = new Float32Array([NaN]); f32[0] >>> 0 // (expected NaN) Additionally, NaN bit patterns don't match WebIDL draft: http://www.w3.org/TR/WebIDL/#es-float http://www.w3.org/TR/WebIDL/#es-double var buf = new Uint8Array(8), dv = new DataView(buf.buffer); dv.setFloat64(0, NaN); dv.getUint32(0).toString(16); >>> "fff80000" dv.getUint32(1).toString(16); >>> "0" // Expected: 0x7ff8000000000000 dv.setFloat32(0, NaN); dv.getUint32(0).toString(16); >>> "ffc00000" // Expected: 0x7fc00000 Note that changing the WebIDL draft is an valid option as well if these values can be justified as making more sense. Alternately, the Typed Array specification could indicate that no explicit bit pattern for NaNs can be guaranteed - IEEE 754 defines a variety of NaN values, and for allowing variability among platforms may allow higher performance implementations.
Attachments
Joshua Bell
Comment 1 2011-02-02 09:10:28 PST
Ooops - I previously reported the first issue as https://bugs.webkit.org/show_bug.cgi?id=46990
Kenneth Russell
Comment 2 2011-02-02 10:37:33 PST
To be clear: - Float32Array is working properly; the first few cases are working correctly in top of tree Chromium. - DataView seems to still have some corner case bugs around handling of NaNs. Jian Li, do you have time to look into this?
Jian Li
Comment 3 2011-02-07 11:46:49 PST
Kenneth Russell
Comment 4 2011-02-07 14:43:11 PST
Please see the V8 bug http://code.google.com/p/chromium/issues/detail?id=71979 for some additional thoughts. I'm inclined to relax the Typed Array spec in this area because if high-performance JavaScript engines like V8 avoid canonicalizing the NaN representation, it is strongly desirable to avoid impacting the performance of typed arrays in order to do so. Detecting and canonicalizing NaN would definitely negatively impact the performance of Float32Array's indexed setter.
Joshua Bell
Comment 5 2011-02-07 16:25:16 PST
Relaxing the Typed Array spec is fine with me.
Kenneth Russell
Comment 6 2011-02-08 15:52:26 PST
After discussion on the public_webgl list, this behavior is being left unspecified. Closing as Invalid.
Note You need to log in before you can comment on or make changes to this bug.