According to the JLS:
"NaN is unordered, so the numerical comparison operators <, <=, >, and >= return false if either or both operands are NaN. The equality operator == returns false if either operand is NaN, and the inequality operator != returns true if either operand is NaN."
Problems can ensue when the programmer uses such operators on NaN values in comparison operations. There is also a possibility that the input validation condition does not expect a NaN
value as input.
Non-compliant Code Example
A frequently encountered mistake is the doomed comparison with NaN
, typically in expressions. As per its semantics, no value can be compared to NaN
using common operators, including NaN
itself. This non-compliant example demonstrates one of such cases.
public class NaNComparison { public static void main(String[] args) { double result = Double.NaN; if(result == Double.NaN) System.out.println("Both are equal"); } }
Compliant Solution
This compliant solution uses Double.isNaN
to check if the expression corresponds to a NaN
value.
public class NaNComparison { public static void main(String[] args) { double result = Double.NaN; if(Double.isNaN(result)) System.out.println("Both are equal"); } }
Risk Assessment
Comparisons with NaN values may lead to unexpected results.
Rule |
Severity |
Likelihood |
Remediation Cost |
Priority |
Level |
---|---|---|---|---|---|
EXP01-J |
low |
unlikely |
medium |
P?? |
L?? |
Automated Detection
TODO
Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
References
[[JLS 05]] Section 4.2.3 Floating-Point Types, Formats, and Values
[[FindBugs 08]] FE: Doomed test for equality to NaN