[Cfp-interest 3074] Re: <math.h> macros and exceptions

[Jim Thomas]

We discussed this thread at the March 2024 CFP meeting, nominally as Issue 5 in the list in C26D (https://wiki.edg.com/pub/CFP/WebHome/c26d.htm). By my count, there are four issues in the thread that need response. Rajan took an action item to draft fixes for two of them, which he did in

o	[Cfp-interest 3045] Action item for Rajan: C26 issue 5 version 2

However, no action items were assigned for two others where I believe we had agreement. Suggested action items follow.

> On Mar 8, 2024, at 4:21 PM, Jim Thomas <jaswthomas at sbcglobal.net> wrote:
> 
> Do we intend for the evaluation of any object-like macros defined in Clause 7 or Annexes F, G, H or K to raise a floating-point exception at execution time? If not, we might add that as a requirement in 7.1.2. See 7.1.2 #7 (in n3219).

Suggested action item: Write a proposal for the following change: 

After 7.1.2 #7, insert the paragraph

The evaluation of the replacement for an object-like macro described in this clause or Annexes F, Annex G, Annex H, or Annex K shall not raise a floating-point exception.

This addresses original Issue 5. The sentence follows the form of a similar one in 7.1.2 #7.

> 
>> On Feb 11, 2024, at 9:58 AM, Fred J. Tydeman <tydeman at tybor.com <mailto:tydeman at tybor.com>> wrote:
>> 
>> On Wed, 7 Feb 2024 19:37:46 +0000 Rajan Bhakta wrote:
>>> 
>>>       Jim:  Are there any <math.h> macros with this issue?  Should words be added to an introduction section in <float.h>?
>>>       ^Fred: Look into.
>> 
>> <math.h> macros that should not raise exceptions when evaluated:
>> 
>> HUGE_VAL, HUGE_VALF, HUGE_VALL, HUGE_VAL_D*
>> INFINITY, DEC_INFINITY
>> NAN, DEC_NAN
>> 
>> 
>> Aside:  Should 7.12.1#5 (overflow) mention HUGE_VAL_D*?
> 
> Right. Perhaps change 
> 
> returns the value of the macro HUGE_VAL, HUGE_VALF, or HUGE_VALL according to the return type
> 
> to
> 
> returns the value of the macro HUGE_VAL suffixed according to the return type
> 
> which would cover the macros in Annex H too.

Suggested action item: Write a proposal for the following change.

In 7.12.1 #5, change

… the function returns the value of the macro HUGE_VAL, HUGE_VALF, or HUGE_VALL according to the return type ...

to

… the function returns the value of the macro HUGE_VAL suffixed according to the return type ...


> 
>> 
>> SNAN macro "requirement" is in a Recommended practice in F.2.1.
> 
> I think it's F.2.2 in n3219. It doesn't use “shall” or a form of “require”. Are you interpreting “raises” (in recommended practice) as a requirement?
> 
>> 
>> FLTn_SNAN, DECn_SNAN, FLTnx_SNAN, DECnx_SNAN in H.3#6
>> HUGE_VAL_Fn, HUGE_VAL_Dn, HUGE_VAL_Fnx, HUGE_VAL_Dnx in H.11.1

I believe we decided no followup is needed for this issue, unless a problem is identified.
>> 
>> Aside:  5.2.4.2.2#22 mentions SNAN for translation time initializer,
>> while H.3#6 mentions static or thread storage duration.
> 
> Good catch. I think it’s 5.2.5.3.2#28 in n3219. Is there any reason not to use the words in H.3#6 in both places? 

This is one of the issues Rajan addressed in [Cfp-interest 3045]. In the meantime, Fred added this issue as new Issue 20 in C26D.

During the CFP discussion another issue arose about the specification of initialization with SNAN macros, namely that "an optional unary + or - operator followed by a signaling NaN macro” might suggest erroneously that a unary operator is required. This is the second issue Rajan addressed in [Cfp-interest 3045].

- Jim Thomas

> 
> - Jim Thomas
> 
>> 
>> 
>> ---
>> Fred J. Tydeman        Tydeman Consulting
>> tydeman at tybor.com      Testing, numerics, programming
>> +1 (702) 608-6093      Vice-chair of INCITS/C (ANSI "C")
>> Sample C17+FPCE tests: http://www.tybor.com
>> Savers sleep well, investors eat well, spenders work forever.
>> 
>> _______________________________________________
>> Cfp-interest mailing list
>> Cfp-interest at oakapple.net
>> http://mailman.oakapple.net/mailman/listinfo/cfp-interest
> 
> _______________________________________________
> Cfp-interest mailing list
> Cfp-interest at oakapple.net <mailto:Cfp-interest at oakapple.net>
> http://mailman.oakapple.net/mailman/listinfo/cfp-interest

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20240405/fa1d82fa/attachment.htm>