Proposed resolution:

This wording is relative to N5046.

1. Modify [cmath.syn] as indicated:

   -1- The contents and meaning of the header <cmath> are a subset of the C standard library header <math.h> and only the declarations shown in the synopsis above are present, with the addition of a three-dimensional hypotenuse function ([c.math.hypot3]), a linear interpolation function ([c.math.lerp]), and the mathematical special functions described in [sf.cmath]. [Note 1: Several functions have additional overloads in this document, but they have the same behavior as in the C standard library. — end note]

   -2- The treatment of error conditions specified in ISO/IEC 9899:2024 7.21.1 and the effect of those errors on constant expressions specified in [library.c] applies to all functions described in [c.math] except those in [sf.cmath], even if not defined in the C standard library.

[ 2026-07-10; LWG telecon. ]

Set priority to 3 after LWG telecon. LWG would like blanket wording that says that `lerp` and 3-arg `hypot` (and the extended floating-point type overloads in `cmath`) are also covered by the blanket wording on when C `math.h` functions raise errors and are constant expressions.

Consider the following example, which (mathematically) attempts to compute ∞+0(∞−∞) .

#include <cmath>
#include <limits>

constexpr float inf = std::numeric_limits<float>::infinity();
constexpr float x = std::lerp(inf, inf, 0.f);

MSVC accepts this, but GCC and Clang reject it due to floating-point arithmetic that produces a NaN, within the implementation of `std::lerp`.

[library.c] states that "call to a C standard library function is a non-constant library call if it raises a floating-point exception other than FE_INEXACT", but this does not apply to `std::lerp` because it is not a C standard library function. Since this means there exists no specification of when `std::lerp` raises which floating-point exceptions, all calls to `std::lerp` are constant expressions (?), which is inconsistent with the other functions in <cmath>.

Similarly, the three-dimensional hypotenuse function is missing a specification of when any errors would occur, which is addressed only partially by LWG 3172 by saying that a "range error may occur" without any specification of when exactly that would happen or when a domain error occurs.

A possible direction is to ensure that C23 §7.21.1 Treatment of error conditions applies to three-dimension `std::hypot` and `std::lerp` as well, despite those not being C standard library functions.