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