Bug 53598
| Summary: | [V8] Incorrect behavior of NaNs in DataView (setting values, bit patterns) | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Joshua Bell <inexorabletash> |
| Component: | WebGL | Assignee: | 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
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 | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Joshua Bell
Ooops - I previously reported the first issue as https://bugs.webkit.org/show_bug.cgi?id=46990
Kenneth Russell
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
V8 bug filed: http://code.google.com/p/v8/issues/detail?id=1101
Kenneth Russell
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
Relaxing the Typed Array spec is fine with me.
Kenneth Russell
After discussion on the public_webgl list, this behavior is being left unspecified. Closing as Invalid.