You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 41 Next »

The Java language allows platforms to use available floating point hardware that can provide floating point support with mantissas and/or 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, 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 strictfp modifier has no 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 strictfp modifier increases the likelihood that intermediate operations will overflow or underflow because it restricts the representable range and precision of intermediate values; it can 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 any 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.

Strict behavior cannot be inherited by a subclass that extends a strictfp superclass. An overriding method can 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. If Double.MAX_VALUE is indeed 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.

JVM implementations are not required to report an overflow resulting from the initial multiplication, although they can choose to treat this case as strictfp. The ability to use extended exponent ranges to represent intermediate values is implementation defined.

class Example {
  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

For maximum portability, 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. 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.

strictfp class Example {
  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

On platforms whose native floating point hardware provides greater precision than double, 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.

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();
  }
}

The lost magnitude would also have been lost if the value were stored to memory, for example to a field of type float.

Compliant Solution

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();
  }
}

Risk Assessment

Failure to use the strictfp modifier can result in implementation-defined behavior with respect to the behavior of floating point operations.

Guideline

Severity

Likelihood

Remediation Cost

Priority

Level

NUM09-J

low

unlikely

high

P1

L3

Automated Detection

Sound automated detection of violations of this guideline are not feasible in the general case.

Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this guideline on the CERT website.

Related Guidelines

C Secure Coding Standard FLP00-C. Understand the limitations of floating point numbers

Bibliography

[[Darwin 2004]] Ensuring the Accuracy of Floating-Point Numbers
[[JLS 2005]] Section 15.4, "FP-strict Expressions"
[[JPL 2006]] 9.1.3. Strict and Non-Strict Floating-Point Arithmetic
[[McCluskey 2001]] Making Deep Copies of Objects, Using strictfp, and Optimizing String Performance


      03. Floating Point (FLP)      NUM10-J. Do not attempt comparisons with NaN

  • No labels