The Java language allows platforms to make use of available floating point hardware that may provide floating point support with mantissas and/or exponents that contain more bits than the standard Java primitive type double
, thus enabling those platforms to represent a superset of the values that can be represented by the standard floating point types. Floating point computations on such platforms may 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 Section 15.4 "FP-Strict Expressions": "the net effect, 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."
When it is important to obtain consistent results from floating point operations across different JVMs and platforms, use the strictfp
modifier. This modifier requires the JVM and platform to behave as though all floating point computations were performed using values limited to those representable by a standard Java float
or double
, thus guaranteeing that the result of the computations will match exactly across all JVMs and platforms.
Use of the strict_fp
modifier lacks impact on platforms that lack platform-specific floating point behavior. It can have substantial impact, however, on both the efficiency and the result values of floating point computations when executing on platforms that implement platform-specific floating point behavior. On these platforms, use of the strict_fp
modifier increases the likelihood that intermediate operations will overflow or underflow because it restricts the representable range and precision of intermediate values; it may also reduce computational efficiency. These issues are unavoidable when portability is the main concern.
The strictfp
modifier can be used with a class, method or interface:
Usage |
Strictness Behavior |
---|---|
Class |
All code in the class including (instance, variable, static initializers), code in nested classes |
Method |
All code within the method is subject to strictness constraints |
Interface |
All code in the class that implements the interface is also strict |
An expression is strict when any of the containing classes, methods or interfaces is declared to be a strictfp
. Constant expressions containing floating point operations are also evaluated strictly. All compile-time constant expressions are by default, strictfp
.
The strict behavior cannot be inherited by a subclass that extends a strictfp
superclass. An overriding method may independently choose to be strictfp
when the overridden method is not or vice versa.
Noncompliant Code Example
This noncompliant code example does not mandate strictfp
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 may choose to treat this case as strictfp
. The ability to use extended exponent ranges to represent intermediate values is implementation defined.
class Strictfp { 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 compliant, use the strictfp
modifier within an expression (class, method or interface) to guarantee that intermediate results do not vary because of implementation defined compiler optimizations or by design. This code snippet is guaranteed to return positive INFINITY
because of the intermediate overflow condition.
strictfp class Strictfp { 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."); } }
Risk Assessment
Failure to use the strictfp
modifier can result in platform defined behavior with respect to the accuracy of floating point operations.
Guideline |
Severity |
Likelihood |
Remediation Cost |
Priority |
Level |
---|---|---|---|---|---|
FLP04-J |
low |
unlikely |
high |
P1 |
L3 |
Automated Detection
TODO
Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this guideline on the CERT website.
Bibliography
[[Darwin 2004]] Ensuring the Accuracy of Floating-Point Numbers
[[JLS 2005]] 15.4 FP-strict Expressions
[[JPL 2005]] 9.1.3. Strict and Non-Strict Floating-Point Arithmetic
[[McCluskey 2001]] Making Deep Copies of Objects, Using strictfp, and Optimizing String Performance
FLP03-J. Range check before casting floating point numbers to narrower types 07. Floating Point (FLP) FLP05-J. Do not attempt comparisons with NaN