The Java language allows platforms to use available floating-point hardware that can provide extended floating-point support with exponents that contain more bits than the standard Java primitive type double
(in the absence of the strictfp
modifier). Consequently, these platforms can represent a superset of the values that can be represented by the standard floating-point types. Floating-point computations on such platforms can produce different results than would be obtained if the floating-point computations were restricted to the standard representations of float
and double
. According to the JLS, §15.4, "FP-strict Expressions" [JLS 2005]:
The net effect [of non-fp-strict evaluation], roughly speaking, is that a calculation might produce "the correct answer" in situations where exclusive use of the float value set or double value set might result in overflow or underflow.
Programs that require Sometimes it is desired to obtain consistent results from floating-point operations , across different JVMs and platforms must use the strictfp
modifier. This modifier requires the JVM and the platform to behave as though all floating-point computations were performed using values limited to those that can be represented by a standard Java float
or double
, guaranteeing that the result of the computations will match exactly across all JVMs and platforms.
Using the strictfp
modifier leaves execution unchanged on platforms that lack platform-specific, extended floating-point support. It can have substantial impact, however, on both the efficiency and the resulting values of floating-point computations when executing on platforms that provide extended floating-point support. On these platforms, using the strictfp
modifier increases the likelihood that intermediate operations will overflow or underflow because it restricts the range of intermediate values that can be represented; it can also reduce computational efficiency. These issues are unavoidable when portability is the main concern.
. This guarantee is imposed by the strictfp
modifier which ensures that intermediate operations do not result in arithmetic underflow or overflow commonly encountered while dealing with float
and double
types. The strictfp
modifier can be used with a class, method, or interface. :
UsageStrictness | BehaviorApplies to |
---|---|
Class | All code in the class including (instance, variable, static initializers) initializers, and code in nested classes |
Method | All code within the method is subject to strictness constraints |
Interface | All code in the any class that implements the interface is also strict |
An expression is FP-strict if when any of the contained containing classes, methods and , or interfaces is defined declared to be a strictfp
. Constant expressions containing floating-point operations are also evaluated strictly. All compile-time constant expressions are by default , strictfp
FP-strict.
Notably, the strict behavior cannot be Strict behavior is not inherited by a subclass that extends a strictfp
FP-strict superclass. An overriding method may can independently choose to be strictfp
FP-strict when the overridden method is not, or vice versa.
Noncompliant Code Example
This noncompliant code example does not enforce the strictfp
constraintsmandate FP-strict computation. Double.MAX_VALUE
is being multiplied by 1.1 and reduced back by dividing by 1.1, according to the evaluation order. JVM implementations are not required to report an overflow resulting from the initial multiplication, although they can chose . If Double.MAX_VALUE
is the maximum value permissible by the platform, the calculation will yield the result infinity
.
However, if the platform provides extended floating-point support, this program might print a numeric result roughly equivalent to Double.MAX_VALUE
.
The JVM may choose to treat this case as strictfp
. The ability to use extended exponent ranges to represent intermediate values is as a result implementation definedFP-strict; if it does so, overflow occurs. Because the expression is not FP-strict, an implementation may use an extended exponent range to represent intermediate results.
Code Block | ||
---|---|---|
| ||
class StrictfpExample { public static void main(String[] args) { double d = Double.MAX_VALUE; System.out.println("This value \"" + ((d * 1.1) / 1.1) + "\" cannot be represented as double."); } } |
Compliant Solution
To be compliantFor maximum portability, use the strictfp
modifier within an expression (class, method, or interface) to guarantee that intermediate results do not vary due to because of implementation-defined compiler optimizations or by design. This code snippet is guaranteed to return positive INFINITY
due to behavior. The calculation in this compliant solution is guaranteed to produce infinity
because of the intermediate overflow condition, regardless of what floating-point support is provided by the platform.
Code Block | ||
---|---|---|
| ||
strictfp class StrictfpExample { public static void main(String[] args) { double d = Double.MAX_VALUE; System.out.println("This value \"" + ((d * 1.1) / 1.1) + "\" cannot be represented as double."); } } |
Noncompliant Code Example
Native floating-point hardware provides greater range than double
. On these platforms, the JIT is permitted to use floating-point registers to hold values of type float
or type double
(in the absence of the strictfp
modifier), even though the registers support values with greater exponent range than that of the primitive types. Consequently, conversion from float
to double
can cause an effective loss of magnitude.
Code Block | ||
---|---|---|
|
Risk Assessment
class Example {
double d = 0.0;
public void example() {
float f = Float.MAX_VALUE;
float g = Float.MAX_VALUE;
this.d = f * g;
System.out.println("d (" + this.d + ") might not be equal to " +
(f * g));
}
public static void main(String[] args) {
Example ex = new Example();
ex.example();
}
}
|
Magnitude loss would also occur if the value were stored to memory – for example, to a field of type float
.
Compliant Solution
This compliant solution uses the strictfp
keyword to require exact conformance with standard Java floating-point. Consequently, the intermediate value of both computations of f * g
is identical to the value stored in this.d
, even on platforms that support extended range exponents.
Code Block | ||
---|---|---|
| ||
strictfp class Example {
double d = 0.0;
public void example() {
float f = Float.MAX_VALUE;
float g = Float.MAX_VALUE;
this.d = f * g;
System.out.println("d (" + this.d + ") might not be equal to " +
(f * g));
}
public static void main(String[] args) {
Example ex = new Example();
ex.example();
}
}
|
Exceptions
NUM06-J-EX0: This rule applies only to calculations that require consistent floating-point results on all platforms. Applications that lack this requirement need not comply.
Risk Assessment
Failure to use Not using the strictfp
modifier can result in platform nonportable, implementation-defined behavior with respect to the accuracy behavior of floating-point operations.
Rule | Severity | Likelihood | Remediation Cost | Priority | Level |
---|---|---|---|---|---|
FLP03NUM06-J | low | unlikely | high | P1 | L3 |
Automated Detection
TODO
Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
References
Wiki Markup |
---|
\[[JLS 05|AA. Java References#JLS 05]\] 15.4 FP-strict Expressions
\[[JPL 05|AA. Java References#JPL 05]\] 9.1.3. Strict and Non-Strict Floating-Point Arithmetic
\[[McCluskey 01|AA. Java References#McCluskey 01]\] Making Deep Copies of Objects, Using strictfp, and Optimizing String Performance
\[[Darwin 04|AA. Java References#Darwin 04]\] Ensuring the Accuracy of Floating-Point Numbers |
Related Guidelines
FLP00-C. Understand the limitations of floating-point numbers | |
VOID FLP00-CPP. Understand the limitations of floating-point numbers |
Bibliography
Ensuring the Accuracy of Floating-Point Numbers | |
[JLS 2005] | |
[JPL 2006] | 9.1.3, Strict and Non-Strict Floating-Point Arithmetic |
Making Deep Copies of Objects, Using strictfp, and Optimizing String Performance |
...
FLP02-J. Do not attempt comparisons with NaN 07. Floating Point (FLP) FLP04-J. Check floating point inputs for exceptional values