...
Note that conversions from float
to double
can also lose information about the overall magnitude of the converted value. See rule "NUM06-J. Use the strictfp modifier for floating point calculation consistency across platforms" for additional information.
Noncompliant Code Example
In this noncompliant code example, two identical large integer literals are passed as arguments to the subFloatFromInt()
method. The second argument is coerced to float
, cast back to int
, and subtracted from a value of type int
. The result is returned as a value of type int
.
...
Note that conversions from long
to either float
or double
can lead to similar loss of precision.
Compliant Solution (ArithmeticException
)
This compliant solution range checks the argument of the integer argument (op1
) to ensure it can be represented as a value of type float
without a loss of precision.
...
In this example, the subFloatFromInt()
method throws java.lang.ArithmeticException
. This general approach, with appropriate range checks, should be used for conversions from long
to either float
or double
.
Compliant Solution (Wider Type)
This compliant solution accepts an argument of type double
instead of an argument of type float
. Values of type double
have 52 mantissa bits, a sign bit, and an 11 bit exponent. Integer values of type int
and narrower can be converted to double
without a loss of precision.
...
Note that this compliant solution cannot be used when the primitive integers are of type long
because Java lacks a primitive floating-point type whose mantissa can represent the full range of a long
.
Risk Assessment
Converting integer values to floating-point types whose mantissa has fewer bits than the original integer value can result in a rounding error.
Rule | Severity | Likelihood | Remediation Cost | Priority | Level |
---|---|---|---|---|---|
NUM17-J | low | unlikely | medium | P2 | L3 |
Automated Detection
Automatic detection of casts that can lose precision is straightforward. Sound determination of whether those casts correctly reflect the intent of the programmer is infeasible in the general case. Heuristic warnings could be useful.
Related Guidelines
C Secure Coding Standard | "FLP36-C. Beware of precision loss when converting integral types to floating point" |
C++ Secure Coding Standard | "FLP36-CPP. Beware of precision loss when converting integral types to floating point" |
Bibliography
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="ce236762cc5f980d-119c98f5-401f49a2-b9bba409-f44b924b785fd323c6ca9fba"><ac:plain-text-body><![CDATA[ | [[JLS 2005 | AA. Bibliography#JLS 05]] | [§5.1.2, "Widening Primitive Conversion" | http://java.sun.com/docs/books/jls/third_edition/html/conversions.html#5.1.2] | ]]></ac:plain-text-body></ac:structured-macro> |
...