I have only noticed this with the 32bit interpreter on linux, the 64bit produces correct results and the 32bit mac produces correct results. // 1) Infinity/f -> should produce a number, since Infinity is a number // 2) float == Number // 3) should coerce float via ToNumber var f:float = -0.0f print(float.NEGATIVE_INFINITY == Infinity/f); print(Number(float.NEGATIVE_INFINITY) == Infinity/f); lin32 -Dinterp: false true expected: true true Testmedia: as3/Types/Float/flt_4_5_17.as as3/Types/Float/flt_4_5_18.as as3/Types/Float/flt_4_5_20.as as3/Types/Float/flt_6_8_1.as as3/Types/Float/flt_6_8_2.as
Test needs to print the value of Infinity/f to ensure that it is actually -Infinity, I suspect the -0f is a more likely culprit than ==.
(In reply to Lars T Hansen from comment #1) > Test needs to print the value of Infinity/f to ensure that it is actually > -Infinity, I suspect the -0f is a more likely culprit than ==. print(Infinity/f); -Infinity Both -Dinterp and -Ojit with linux 32bit
Isolated to a changeset: 6774:f945faabe92e (getting rid of the number_d hack; isNumber now means "isNumber", added "isNumberOrFloat" + "isNumeric".) 6773:7b17a0adbadb (-Dinterp) true true -Infinity 6774:f945faabe92e (-Dinterp) false true -Infinity
Mistery solved: Atom is signed, and thus the test in isNumeric is wrong (i.e. a non-null bibop pointer may be <trueAtom).
fixed in changeset 6791:ead4a42c6429
Verified fix in changeset 6791:ead4a42c6429, removed expected failures from testconfig in 6795:63bef4ee7d8a
changeset: 6876:4594bf78592e user: Brent Baker <firstname.lastname@example.org> summary: Bug 700258: track current expected failures on linux32 http://hg.mozilla.org/tamarin-redux/rev/4594bf78592e