id,summary,reporter,owner,description,type,status,priority,milestone,component,version,severity,resolution,keywords,cc,lang,patch,platform
1965,rational.pmc's get_bool is backwards and not portable,doughera,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.",bug,closed,normal,,testing,2.11.0,medium,fixed,,,,applied,