[cfp-interest 3742] Re: Complex and 'any floating-point operator'

[Jim Thomas]

> On Nov 30, 2025, at 4:18 AM, Damian McGuckin <damianm at esi.com.au> wrote:
> 
> 
> 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).

Given that the behavior of signaling NaNs is implementation-defined here, per G.6.1 #5, doesn’t whether “invalid” is raised depend on what the implementation documents? 

(BTW, I think the result value of the conversion is determined by 6.3.1.2, which is not overridden by G.6.1 #5. Annex G is intended to add to the specification in the main standard, but not contradict it.)

- Jim Thomas


> 
> I need to ponder that a bit more.
> 
> Thanks - Damian
> _______________________________________________
> cfp-interest mailing list
> cfp-interest at oakapple.net
> http://mailman.oakapple.net/mailman/listinfo/cfp-interest