[Gnash-dev] [patch] Get Date.as test working on 32-bit machines?

[Petter Reinholdtsen]

The testsuite currently seem to fail like this on 32-bit machines:

 --=[ testsuite/actionscript.all ]=-- 
FAIL: astests-v5-Runner: expected: 584 obtained: 64 [./Date.as:552]
FAIL: astests-v5-Runner: expected: 0 obtained: 8 [./Date.as:553]
FAIL: astests-v5-Runner: expected: 584 obtained: 64 [./Date.as:554]
FAIL: astests-v5-Runner: expected: 0 obtained: 8 [./Date.as:555]
FAIL: astests-v5-Runner: expected: 4 obtained: 45 [./Date.as:556]
FAIL: astests-v6-Runner: expected: 584 obtained: 64 [./Date.as:552]
FAIL: astests-v6-Runner: expected: 0 obtained: 8 [./Date.as:553]
FAIL: astests-v6-Runner: expected: 584 obtained: 64 [./Date.as:554]
FAIL: astests-v6-Runner: expected: 0 obtained: 8 [./Date.as:555]
FAIL: astests-v6-Runner: expected: 4 obtained: 45 [./Date.as:556]
FAIL: astests-v7-Runner: expected: 584 obtained: 64 [./Date.as:552]
FAIL: astests-v7-Runner: expected: 0 obtained: 8 [./Date.as:553]
FAIL: astests-v7-Runner: expected: 584 obtained: 64 [./Date.as:554]
FAIL: astests-v7-Runner: expected: 0 obtained: 8 [./Date.as:555]
FAIL: astests-v7-Runner: expected: 4 obtained: 45 [./Date.as:556]
FAIL: astests-v8-Runner: expected: 584 obtained: 64 [./Date.as:552]
FAIL: astests-v8-Runner: expected: 0 obtained: 8 [./Date.as:553]
FAIL: astests-v8-Runner: expected: 584 obtained: 64 [./Date.as:554]
FAIL: astests-v8-Runner: expected: 0 obtained: 8 [./Date.as:555]
FAIL: astests-v8-Runner: expected: 4 obtained: 45 [./Date.as:556]

The problematic code in question is this:

    h = new Date(3.0935415006117e+23);
    check_equals(h.valueOf().toString(), "3.0935415006117e+23");
    check_equals(h.getMilliseconds(), 584);
    check_equals(h.getSeconds(), 0);
        check_equals(h.getUTCMilliseconds(), 584);
        check_equals(h.getUTCSeconds(), 0);
        check_equals(h.getUTCMinutes(), 4);
        check_equals(h.getUTCDay(), 2);

According to Benjamin Wolsey on IRC, the cause is that JavaScript
represent all numbers as floating point numbers, and the calculation
on this large number differ depending on the architecture / floating
point resolution.

A fix might be to reduce the size of the number to one that work well
on both 64-bit and 32-bit machines.

diff --git a/testsuite/actionscript.all/Date.as 
b/testsuite/actionscript.all/Date.as
index e1a6904..d3c6149 100644
--- a/testsuite/actionscript.all/Date.as
+++ b/testsuite/actionscript.all/Date.as
@@ -547,14 +547,14 @@ note("The pp is known to fail the next three tests");
        check_equals(wierddate.getMilliseconds(), 700);
        check_equals(wierddate.getFullYear(), -100000);

-    h = new Date(3.0935415006117e+23);
-    check_equals(h.valueOf().toString(), "3.0935415006117e+23");
-    check_equals(h.getMilliseconds(), 584);
-    check_equals(h.getSeconds(), 0);
-       check_equals(h.getUTCMilliseconds(), 584);
-       check_equals(h.getUTCSeconds(), 0);
-       check_equals(h.getUTCMinutes(), 4);
-       check_equals(h.getUTCDay(), 2);
+    h = new Date(3.0935415006117e+15);
+    check_equals(h.valueOf().toString(), "3.0935415006117e+15");
+    check_equals(h.getMilliseconds(), 700);
+    check_equals(h.getSeconds(), 11);
+       check_equals(h.getUTCMilliseconds(), 700);
+       check_equals(h.getUTCSeconds(), 11);
+       check_equals(h.getUTCMinutes(), 30);
+       check_equals(h.getUTCDay(), 1);

 // It's hard to test TimezoneOffset because the values will be different
 // depending upon where geographically you run the tests.

I have tested this change on a 32-bit build, but can't test it on
64-bit.  Is it a good idea to change the test like this?

Happy hacking,
-- 
Petter Reinholdtsen