20.5.1 FP Exceptions

The IEEE 754 standard defines five exceptions that can occur during a calculation. Each corresponds to a particular sort of error, such as overflow.

When exceptions occur (when exceptions are raised, in the language of the standard), one of two things can happen. By default the exception is simply noted in the floating-point status word, and the program continues as if nothing had happened. The operation produces a default value, which depends on the exception (see the table below). Your program can check the status word to find out which exceptions happened.

Alternatively, you can enable traps for exceptions. In that case, when an exception is raised, your program will receive the SIGFPE signal. The default action for this signal is to terminate the program. See Signal Handling, for how you can change the effect of the signal.

In the System V math library, the user-defined function matherr is called when certain exceptions occur inside math library functions. However, the Unix98 standard deprecates this interface. We support it for historical compatibility, but recommend that you do not use it in new programs. When this interface is used, exceptions may not be raised.

The exceptions defined in IEEE 754 are:

‘Invalid Operation’

This exception is raised if the given operands are invalid for the operation to be performed. Examples are (see IEEE 754, section 7):

1. Addition or subtraction: ∞ - ∞. (But ∞ + ∞ = ∞).
2. Multiplication: 0 · ∞.
3. Division: 0/0 or ∞/∞.
4. Remainder: x REM y, where y is zero or x is infinite.
5. Square root if the operand is less then zero. More generally, any mathematical function evaluated outside its domain produces this exception.
6. Conversion of a floating-point number to an integer or decimal string, when the number cannot be represented in the target format (due to overflow, infinity, or NaN).
7. Conversion of an unrecognizable input string.
8. Comparison via predicates involving < or >, when one or other of the operands is NaN. You can prevent this exception by using the unordered comparison functions instead; see FP Comparison Functions.

If the exception does not trap, the result of the operation is NaN.

‘Division by Zero’

This exception is raised when a finite nonzero number is divided by zero. If no trap occurs the result is either +&infin; or -&infin;, depending on the signs of the operands.

‘Overflow’

This exception is raised whenever the result cannot be represented as a finite value in the precision format of the destination. If no trap occurs the result depends on the sign of the intermediate result and the current rounding mode (IEEE 754, section 7.3):

1. Round to nearest carries all overflows to &infin; with the sign of the intermediate result.
2. Round toward 0 carries all overflows to the largest representable finite number with the sign of the intermediate result.
3. Round toward -&infin; carries positive overflows to the largest representable finite number and negative overflows to -&infin;.
4. Round toward &infin; carries negative overflows to the most negative representable finite number and positive overflows to &infin;.

Whenever the overflow exception is raised, the inexact exception is also raised.

‘Underflow’

The underflow exception is raised when an intermediate result is too small to be calculated accurately, or if the operation’s result rounded to the destination precision is too small to be normalized.

When no trap is installed for the underflow exception, underflow is signaled (via the underflow flag) only when both tininess and loss of accuracy have been detected. If no trap handler is installed the operation continues with an imprecise small value, or zero if the destination precision cannot hold the small exact result.

‘Inexact’

This exception is signalled if a rounded result is not exact (such as when calculating the square root of two) or a result overflows without an overflow trap.