[cfp-interest 3740] Re: Complex and 'any floating-point operator'
Damian McGuckin
damianm at esi.com.au
Sun Nov 30 04:18:21 PST 2025
Hi Fred,
To stimulate conversation,
On Thu, 27 Nov 2025, Fred J. Tydeman wrote:
> WG14 N3219 (C23), F.2.2, paragraph 6 has:
>
> Recommended practice
>
> Any floating-point operator or <math.h> function or macro with a signaling
> NaN input, unless explicitly specified otherwise, raises an "invalid"
> floating-point exception.
>
> My question is: Since 'Any floating-point operator' is not qualified
> with 'real', does that mean it applies to 'complex' operators?
In the context of Annex F, technically, yes.
In the context of Annex G, technically, No. Because, once you get to
Annex G, as you clearly note, you have a "catch-all" clause G.6.1#5:
>
> G.6.1 paragraph 5 has:
> In subsequent subclauses in G.6 "NaN" refers to a quiet NaN. The behavior of
> signaling NaNs in this annex is implementation-defined.
This is an all encompassing clause and "behaviour" would include its use
with both basic operators and as a parameter to functions and macros.
>
> There is no mention of 'operator' in Annex G with respect to signaling NaN.
Should we tweak G.6.1#5 to expand on the definition of "behaviour"?
> Aside: Paragraph 4 has: "Any operator or <math.h> function ..."
> while paragraph 6 has: "Any floating-point operator or <math.h> function or macro..."
> Seems inconsistent.
That has been corrected. Please see the suggested update on the Wiki
https://wiki.edg.com/pub/CFP/WebHome/C2Y-F-2-2-Only-20251015.pdf
> The question arose from:
> bool b1 = CMPLXL( 1.L/3.L, LDBL_SNAN ); /* no FE_INVALID */
> bool b2 = CMPLXL( LDBL_SNAN, 1.L/3.L ); /* yes FE_INVALID */
>
> Where the generated code first checks the real part for non-zero
> (in which case if never checks the imaginary part for non-zero;
> thereby, never looking at the SNAN in the first case).
I need to ponder that a bit more.
Thanks - Damian
More information about the cfp-interest
mailing list