#1965: rational.pmc's get_bool is backwards and not portable
----------------------+-----------------------------------------------------
Reporter: doughera | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: none | Version: 2.11.0
Severity: medium | Keywords:
Lang: | Patch: new
Platform: |
----------------------+-----------------------------------------------------
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.
--
Ticket URL: <https://trac.parrot.org/parrot/ticket/1965>
Parrot <https://trac.parrot.org/parrot/>
Parrot Development
_______________________________________________
parrot-tickets mailing list
[email protected]
http://lists.parrot.org/mailman/listinfo/parrot-tickets
