Ticket #1965 (closed bug: fixed)
rational.pmc's get_bool is backwards and not portable
|Reported by:||doughera||Owned by:||dukeleto|
I am seeing the following failure in t/dynpmc/rational.t:
./parrot t/dynpmc/rational.t 1..78 Floating point exception
The problem is that the Rational get_bool vtable does this:
if (mpq_cmp_si(RT(SELF), 0, 0)) return 0; else return 1;
That is, it compares a value with 0/0, which, naturally, raises a divide-by-zero exception. (I haven't traced it carefully, but I think if gmp is compiled by gcc, a different set of macros kick in, which handle this case differently.) The sense of the comparison is strange too: Why is 0/0 considered "true", but everything else "false"? I think it's backwards by accident.
The failure is first triggered by the test_init function, which does
.sub test_init new $P1, 'Rational' ok($P1,'initialization') .end
The ok function is the one that ends up calling get_bool.
The basic question is this: Why not compare with 0/1? This is at least reasonably analagous to what the get_bool vtable does for integers, and avoids any corner cases with 0/0.
The attached patch does that. It also fixes two tests: First, test_init was backwards. The initial default value is 0/1 (which was previously testing as "ok", since the cmp test was backwards). The test now explicitly tests for the expected default value. Second, test_bool now works, and tests both true and false.