On 9/01/2019 4:43 pm, JC Beyler wrote:
Hi David,
I was not planning on doing it but we could. This change came from a
request to remove the booleans from tests for a prior webrev change.
I've seen previous conversations about wanting to test explicitly
against JNI_TRUE but thought this was a slightly different case.
The basic hotspot style rule is "avoid implicit booleans".
Basically, from your comment, it seems I could go three ways for this
change:
1) Not do it and close the bug as won't fix :-)
Certainly the path of least resistance. :)
2) Go the extra step and change the various variables being tested to
bool
My preference is to do (2) as much as possible; any case that cannot be
put in a boolean form without having major changes to the code base, I'd
leave as is. And then call it a day for this subject.
What do you think (ie in cases where the variable can be set to a bool,
do it and then have the test be an implicit test)?
It's really up to you. It seems a lot of work and I don't know if you
can actually push this all the way through without needing some
int<->bool conversion somewhere anyway.
Cheers,
David
Thanks!
Jc
On Tue, Jan 8, 2019 at 10:31 PM David Holmes <david.hol...@oracle.com
<mailto:david.hol...@oracle.com>> wrote:
Hi Jc,
On 9/01/2019 4:12 pm, JC Beyler wrote:
> Hi all,
>
> Fixing up the tests in vmTestbase to not be testing explicitly
against
> NSK_TRUE/NSK_FALSE. Here is the webrev to do that:
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8212959
> Webrev: http://cr.openjdk.java.net/~jcbeyler/8212959/webrev.00/
Hold up! We don't do explicit tests when the variable is a bool/boolean
but when it is an int, as here, we do.
Are you planning on converting everything to use bool?
Cheers,
David
> Thanks,
> Jc
--
Thanks,
Jc
