P3899R1 — Clarify the behavior of floating-point overflow

P3899R1 — Clarify the behavior of floating-point overflow (6 items) SG6, EWG, CWG

Jan Schultke, Matthias Kretz

The current C++ specification of floating-point overflow is ambiguous, with disputed interpretations of whether overflow, infinity propagation, or merely yielding infinity constitutes undefined behavior. This paper proposes that floating-point overflow is well-defined and produces infinity when infinity is representable in the type, but that expressions producing infinity or NaN from finite operands are not core constant expressions, while propagation of infinity or quiet NaN remains a valid constant expression. The paper provides revised wording for [basic.fundamental], [expr.pre], and [expr.const] to clearly specify these rules, aligning core language behavior with the standard library's constexpr mathematical functions.

§6.2 [expr.pre], proposed example code block — The comment on 'inf * 0' implies undefined behavior, but under the proposed [expr.pre] wording, inf * 0 is defined (NaN is representable in float32_t). The expression is ill-formed only because the proposed [expr.const] rule rejects 'result is NaN from non-NaN operands.' The comment gives the wrong normative reason; it should cite [expr.const], matching the pattern used for the oflo line. [1]
§6.2 [expr.pre], drafting note — ISO standard number '60599' is a transposition of '60559'. The correct designation is ISO/IEC 60559, consistent with the rest of the paper and the bibliography. [2]
§2.1.1 vs §6.1 [basic.fundamental] — Both passages quote the same note from [basic.fundamental] p13, but §2.1.1 uses 'ISO/IEC/IEEE 60559' while the §6.1 diff-block uses 'ISO/IEC 60559', dropping 'IEEE'. The paper contradicts itself about what the baseline normative text says. [3]
§3.3 Floating-point underflow — The clause 'underflow is' lacks a predicate complement, making the sentence grammatically incomplete. A completion such as 'is undefined behavior' or 'is not a constant expression' is needed. [4]
§2 Introduction — 'finite operands are used as operands' is tautologically redundant; 'operands' appears twice in the same clause. [5]
§3.3 Floating-point underflow — Erroneous article 'a' before the adjective 'well-defined'; the phrase should read 'is well-defined and should be a constant expression' without the extra article. [6]

References — Anthropic Citations API

[1]
"Floating-point underflow (that is, producing zero or a denormalized number, except for exact results) should be a well-defined and should be a constant expression."

[2]
"this is a convenient way of writing an example in terms of a type that definitely adheres to ISO/IEC 60599"

[3]
"Floating-point overflow occurs when finite operands are used as operands, and the result cannot be represented as a finite value."

[4]
"Also, none of the wording suggests that underflow is or that it wouldn't be a constant expression."

[5]
"In §2.1.1: "Since negative and positive infinity are representable in ISO/IEC/IEEE 60559 formats, all real numbers lie within the range of representable values of a floating-point type adhering to..."

[6]
"constexpr std::float32_t udef = inf * 0; // error: result is not mathematically defined"

Summary: P3899R1 proposes normative wording to make floating-point overflow, division by zero, and invalid operations well-defined (producing infinity or NaN per IEEE 60559) rather than undefined behavior, while restricting such results from constant expressions. It also clarifies that floating-point underflow is not undefined behavior.

Pipeline: Discovery (Anthropic Opus + Citations API) → Verification Gate (OpenRouter Opus) → Report Writer (OpenRouter Opus)
Provenance: All references are machine-verified character positions from the Anthropic Citations API — deterministic, exact substrings, not model-generated quotes.