472563 - int wraparound bugs in 64bit builds

Status: VERIFIED FIXED

(Tamarin Graveyard :: Virtual Machine, defect)

Description

[Edwin Smith]

if you run as3/Types/Int/wraparound.abc, a number of tests will say PASSED even though they print the wrong answers.  

for example, comparing the 32bit and 64bit output (interpreter or jit, intel or ppc):

-uint.MIN_VALUE - 1 = 4294967295 = 4294967295 PASSED!
-uint.MIN_VALUE - 1 = 4294967295 = 4294967295 PASSED!
-decrement uint at uint.MIN_VALUE = 4294967295 PASSED!
-uint.MAX_VALUE * 2 = 4294967294 = 4294967294 PASSED!
+uint.MIN_VALUE - 1 = 4294967295 = -1 PASSED!
+uint.MIN_VALUE - 1 = 4294967295 = -1 PASSED!
+decrement uint at uint.MIN_VALUE = -1 PASSED!
+uint.MAX_VALUE * 2 = 4294967294 = -2 PASSED!

-uint.MAX_VALUE << 1 = 4294967294 PASSED!
+uint.MAX_VALUE << 1 = -2 PASSED!

(differential testing FTW!)

Comment 1

[Lars T Hansen]

In the event that these are run in the interpreter; there is already an open bug (https://bugzilla.mozilla.org/show_bug.cgi?id=465754) on dodgy representations that may lead to strange bugs for int values in 64-bit builds.   (May or may not be related, just wanted to note it.)

Comment 2

[Edwin Smith]

Looks like the problem is with string formatting; in a couple places we assume
kIntegerAtom implies int32_t, which isn't right.  Pending fix does a range
check and does unsigned formatting if the value is > 0x7fffffff.  Another fix
would be to change ConvertIntegerToStringBase10 to take intptr_t instead of
int32_t, and internally use a 22 byte buffer instead of 12 byte.  This seems
safer; votes welcome.

Comment 3

[Edwin Smith]

Attachment: use uintToString for kIntegerType Atoms > 0x7fffffff

Comment 4

[Edwin Smith]

pushed changeset:   1267:2b497ebb2153

Comment 5

[Brent Baker]

verified that the as3/Types/Int/wraparound.abc produces the correct values using 32 and 64bit shells