Issue 1100: <math.h> overflow in non-default rounding modes

Authors: Joseph Myers
Date: 2026-09-01
Submitted against: C2Y (N3886 draft)
Status: Open

N3737 made changes to <math.h> error handling that were described as being clarifications.

Those changes added one sentence that is very unclear, with problematic effects on another changed sentence. The unclear sentence is

Range errors in non-default rounding modes are implementation-defined.

in 7.12.2 paragraph 5. This does not say anything about what aspects of range errors are implementation-defined or what the options available to implementations are: whether it's implementation-defined when such errors occur, or what value functions return on such errors, or what exceptions are raised, or what value errno is set to, or any other aspect of how the abstract machine behaves on error. It does not say whether any other sentence describing range errors is still applicable in the case of non-default rounding modes, although normally such sentences would still apply unless specifically excluded. (The case of the value returned is excluded in text referring to HUGE_VAL returned on overflow, which only discusses the return value when "default rounding is in effect".)

Consider the case of a range error for overflow that is specified to "occur", rather than as "may occur", in a non-default rounding mode, for an implementation where math_errhandling & MATH_ERRNO is nonzero. The current wording in 7.12.2 paragraph 7 says:

If a range error occurs because of floating-point overflow and the integer expression math_errhandling & MATH_ERRNO is nonzero, the integer expression errno acquires the value ERANGE.

Previously, this only applied if "default rounding is in effect". Does the implementation-defined behavior act to change all "occur" into "may occur" in a non-default rounding mode, or to make it implementation-defined whether errno is set even when the error occurs? Or does this sentence about overflow now require errno to be set where it was not previously required to be set, with the implementation-defined behavior only changing some smaller aspect that is genuinely unspecified by other text in the standard, such as the precise overflow threshold or the returned value (both of which do depend on the rounding mode in IEC 60559 floating point)?

If errno is now required to be set for some overflows in non-default rounding modes (where it was clearly not previously required to be set), that is problematic because such overflows cannot generally be detected by the implementation from the value it computes, unlike in round-to-nearest, since the largest finite value of the appropriate sign can occur in both overflowing and non-overflowing cases in some rounding modes.