[
https://issues.apache.org/jira/browse/GROOVY-12538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-12538:
-------------------------------
Fix Version/s: 7.0.0-alpha-1
> Primitive double/float > and >= comparisons return true when an operand is NaN
> ------------------------------------------------------------------------------
>
> Key: GROOVY-12538
> URL: https://issues.apache.org/jira/browse/GROOVY-12538
> Project: Groovy
> Issue Type: Bug
> Reporter: Paul King
> Priority: Major
> Fix For: 7.0.0-alpha-1
>
>
> Description:
> When both operands of a comparison are primitive double (or float) values,
> Groovy
> compiles the comparison to a DCMPG (FCMPG) instruction for all four ordered
> operators.
> DCMPG pushes 1 when either operand is NaN, so > and >= evaluate to true;
> javac uses
> DCMPL (FCMPL) for > and >= and DCMPG (FCMPG) for < and <=, so that every
> comparison
> with a NaN operand is false (JLS 15.20.1).
> {code:groovy}
> double n = Double.NaN
> assert !(n > 0.0d) // fails: true
> assert !(n >= 0.0d) // fails: true
> assert !(n < 0.0d) // passes
> assert !(n <= 0.0d) // passes
> float f = Float.NaN
> assert !(f > 0.0f) // fails: true
> {code}
> It affects local variables, fields, static fields and parameters declared
> double or
> float, in dynamic code as well as under @TypeChecked and @CompileStatic. Under
> @CompileStatic it also affects Double.NaN itself, which is a primitive there:
> Double.NaN > 0.0d is false in dynamic code (the field value is boxed) and
> true under
> @CompileStatic.
> Groovy is also inconsistent with itself: for two Double objects, n > 0.0d
> already
> gives false, because the runtime unboxes and uses Java's operator.
> Cause: BinaryDoubleExpressionHelper.getCompareCode() returns DCMPG and
> BinaryFloatExpressionHelper.getCompareCode() returns FCMPG for every operator
> (since the primitive-optimisation backends were added in 2011).
> This is narrower than GROOVY-3309, which asks for NaN comparisons through
> Groovy's
> number comparison (mixed types, ==) to follow IEEE 754 as well. Those paths
> follow
> Double.compareTo/Double.equals by design and are not changed here; <=> already
> matches Double.compare for primitives.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
