C99 Section 7.12.1 defines two types of errors that relate specifically to math functions (as defined in math.h) [[ISO/IEC 9899-1999]]

a domain error occurs if an input argument is outside the domain over which the mathematical function is defined.

a range error occurs if the mathematical result of the function cannot be represented in an object of the specified type, due to extreme magnitude.

An example of a domain error is the square root of a negative number, such as sqrt(-1.0), which has no meaning in real arithmetic. Similarly, ten raised to the one-millionth power, pow(10., 1e6), likely cannot be represented in an implementation's floating point representation and therefore constitutes a range error.

In both cases, the function will return some value, but the value returned is not the correct result of the computation.

Many math errors can be prevented by carefully bounds-checking the arguments before calling functions, and taking alternative action if the bounds are violated. In particular, the following functions should be bounds checked as follows:

However, for some functions it is not practical to use bounds-checking to prevent all errors.  In the above pow example, the bounds check does not prevent the pow(10., 1e6) range error. In these cases detection must be used, either in addition to bounds checking or instead of bounds checking.

acos( x ), asin( x )

Non-Compliant Code Example

The following non-compliant code computes the arc cosine of the variable x

double x, result;

/* Set the value for x */

result = acos(x);

However, this code may produce a domain error if x is not in the range [-1, +1].

Compliant Solution

The following compliant solution uses bounds checking to ensure that there is not a domain error.

double x, result;

/* Set the value for x */

if ( islessequal(x,-1) || isgreaterequal(x, 1) ){
     /* handle domain error */
}

result = acos(x);

atan2( y, x )

Non-Compliant Code Example

The following non-compliant code computes the arc tangent of the two variables x and y.

double x, y, result;

/* Set the value for x and y */

result = atan2(y, x);

However, this code may produce a domain error if both x and y are zero.

Compliant Solution

The following compliant solution tests the arguments to ensure that there is not a domain error.

double x, y, result;

/* Set the value for x and y */

if ( (x == 0.f) && (y == 0.f) ) {
     /* handle domain error */
}

result = atan2(y, x);

log( x ), log10( x )

Non-Compliant Code Example

The following non-compliant code determines the natural logarithm of x.

double result, x;

/* Set the value for x */

result = log(x);

However, this code may produce a domain error if x is negative and a range error if x is zero.

Compliant Solution

The following compliant solution tests the suspect arguments to ensure that no domain errors or range errors are raised.

double result, x;

/* Set the value for x */

if (islessequal(x, 0)) {
  /* handle domain and range errors */
}

result = log(x);

pow( x, y )

Non-Compliant Code Example

The following non-compliant code raises x to the power of y.

double x, y, result;

result = pow(x, y);

However, this code may produce a domain error if x is negative and y is not an integer, or if x is zero and y is zero. A domain error or range error may occur if x is zero and y is negative, and a range error may occur if the result cannot be represented as a double.

Non-Compliant Code Example

This code only performs bounds-checking on x and y. It prevents domain errors and some range errors, but does not prevent range errors where the result cannot be represented as a double (see the Error Checking section below regarding ways to mitigate the effects of a range error).

double x, y, result;

if (((x == 0.f) && islessequal(y, 0)) ||
    (isless(x, 0) && !isInteger(y))) {
  /* handle domain and range errors */
}

result = pow(x, y);

sqrt( x )

Non-Compliant Code Example

The following non-compliant code determines the square root of x

double x, result;

result = sqrt(x);

However, this code may produce a domain error if x is negative.

Compliant Solution

The following compliant solution tests the suspect argument to ensure that no domain error is raised.

double x, result;

if (isless(x, 0)){
  /* handle domain error */
}

result = sqrt(x);

Non-Compliant Coding Example (Error Checking)

The exact treatment of error conditions from math functions is quite complicated (see C99 Section 7.12.1, "Treatment of error conditions").

The sqrt() function returns zero when given a negative argument. The pow() function returns a very large number (appropriately positive or negative) on an overflow range error. This very large number is defined in <math.h> as described by C99 [[ISO/IEC 9899-1999]]:

The macro

HUGE_VAL

expands to a positive double constant expression, not necessarily representable as a float. The macros

HUGE_VALF
HUGE_VALL

are respectively float and long double analogs of HUGE_VAL.

It is best not to check for errors by comparing the returned value against HUGE_VAL or zero for several reasons. First of all, these are in general valid (albeit unlikely) data values. Secondly, making such tests requires detailed knowledge of the various error returns for each math function. Also, there are three different possibilities, -HUGE_VAL, 0, and HUGE_VAL, and you must know which are possible in each case. Finally, different versions of the library have differed in their error-return behavior.

It is also difficult to check for math errors using errno because an implementation might not set it.  For real functions, the programmer can test whether the implementation sets errno because in that case math_errhandling & MATH_ERRNO is nonzero.  For complex functions, the C99 Section 7.3.2 simply states that setting errno is optional.

Compliant Solution (Error Checking)

The most reliable way to test for errors is by checking arguments beforehand, as in the following compliant solution:

if (/* arguments will cause a domain or range error */) {
  /* handle the error */
}
else {
  /* perform computation */
}

For functions where argument validation is difficult, including pow(), erfc(), lgamma(), and tgamma(), one can employ the following approach.

#include <math.h>
#if defined(math_errhandling) && (math_errhandling & MATH_ERREXCEPT)
#include <fenv.h>
#endif

/* ... */

#if defined(math_errhandling) && (math_errhandling & MATH_ERREXCEPT)
  feclearexcept(FE_ALL_EXCEPT);
#endif
errno = 0;

/* call the function */

#if !defined(math_errhandling) || (math_errhandling & MATH_ERRNO)
if (errno != 0) {
  /* handle error */
}
#endif
#if defined(math_errhandling) && (math_errhandling & MATH_ERREXCEPT)
if (fetestexcept(FE_INVALID | FE_DIVBYZERO | FE_OVERFLOW) != 0) {
  /* handle error */
}
#endif

Implementation Details

System V Interface Definition, Third Edition

The System V Interface Definition, Third Edition (SVID3) provides more control over the treatment of errors in the math library. The user can provide a function named matherr that is invoked if errors occur in a math function. This function could print diagnostics, terminate the execution, or specify the desired return-value. The matherr() function has not been adopted by C99, so its use is not generally portable.

Risk Assessment

Failure to properly verify arguments supplied to math functions may result in unexpected results.

Automated Detection

Fortify SCA Version 5.0 with CERT C Rule Pack can detect violations of this rule.

Related Vulnerabilities

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

References

[[ISO/IEC 9899-1999]] Section 7.3, "Complex arithmetic <complex.h>", and Section 7.12, "Mathematics <math.h>"
[[Plum 85]] Rule 2-2
[[Plum 89]] Topic 2.10, "conv - conversions and overflow"

FLP31-C. Do not call functions expecting real values with complex values      05. Floating Point (FLP)       FLP33-C. Convert integers to floating point for floating point operations