53598 2011-02-02 08:54:06 -0800 [V8] Incorrect behavior of NaNs in DataView (setting values, bit patterns) 2011-02-08 15:52:26 -0800 1 1 1 Unclassified WebKit WebGL 528+ (Nightly build) PC Windows 7 RESOLVED INVALID P3 Minor --- 1 inexorabletash kbr enne jianli kbr zmo oldest_to_newest 343992 0 inexorabletash 2011-02-02 08:54:06 -0800 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. 343997 1 inexorabletash 2011-02-02 09:10:28 -0800 Ooops - I previously reported the first issue as https://bugs.webkit.org/show_bug.cgi?id=46990 344050 2 kbr 2011-02-02 10:37:33 -0800 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? 346697 3 jianli 2011-02-07 11:46:49 -0800 V8 bug filed: http://code.google.com/p/v8/issues/detail?id=1101 346815 4 kbr 2011-02-07 14:43:11 -0800 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. 346933 5 inexorabletash 2011-02-07 16:25:16 -0800 Relaxing the Typed Array spec is fine with me. 347759 6 kbr 2011-02-08 15:52:26 -0800 After discussion on the public_webgl list, this behavior is being left unspecified. Closing as Invalid.