[Webkit-unassigned] [Bug 53598] New: Incorrect behavior of NaNs in Typed Arrays (setting values, bit patterns)

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=53598

           Summary: Incorrect behavior of NaNs in Typed Arrays (setting
                    values, bit patterns)
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: PC
        OS/Version: Windows 7
            Status: UNCONFIRMED
          Severity: Normal
          Priority: P2
         Component: WebGL
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: josh at lindenlab.com
                CC: kbr at google.com


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.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.