[Cfp-interest] Fwd: (SC22WG14.12761) Observations on N1631

[Jim Thomas]

Begin forwarded message:

> From: Jim Thomas <jaswthomas at sbcglobal.net>
> Subject: Re: (SC22WG14.12761) Observations on N1631
> Date: October 4, 2012 11:11:29 AM PDT
> To: Joseph S. Myers <jsm at polyomino.org.uk>
> Cc: sc22wg14 at open-std.org
> 
> 
> On Oct 3, 2012, at 4:18 PM, Joseph S. Myers wrote:
> 
>> On Sun, 30 Sep 2012, Jim Thomas wrote:
>> 
>>> On Sep 27, 2012, at 5:45 PM, Joseph S. Myers wrote:
>>> 
>>>> Some more observations, these ones relating to signaling NaNs, and cases 
>>>> where C11 specifies something in math.h as a macro rather than a function:
>>>> 
>>>> * The recommended practice for signaling NaNs (page 18, lines 4-5) is that 
>>>> "[6] Any floating-point operator or <math.h> function with a signaling NaN 
>>>> input, unless explicitly specified otherwise, raises an "invalid" 
>>>> floating-point exception.".  This raises a couple of questions:
>>>> 
>>>> - Is it also recommended practice for comparison and classification 
>>>>  *macros* to raise that exception for signaling NaNs, unless specified 
>>>>  otherwise?  If so, should that be stated explicitly, so it's part of 
>>>>  the recommended practice included in the FE_SNANS_ALWAYS_SIGNAL 
>>>>  semantics?
>>> 
>>> Yes, the recommended practice applies to the comparison and 
>>> classification macros. The new issignaling macro explicitly states that 
>>> it determines its result "without raising a floating-point exception". 
>>> Other classification macros should, according to the recommended 
>>> practice, raise the "invalid" floating-point exception if an argument is 
>>> a signaling NaN. So should the comparison macros. Suggested changes to 
>>> the descriptions of the comparison macros in 7.12.14 are intended to 
>>> admit the recommended practice (but not require it). Is there something 
>>> we're missing?
>> 
>> What's missing is something saying "macro" alongside "function", so that 
>> this is explicitly included in the recommended practice (and so included 
>> in what must be implemented if FE_SNANS_ALWAYS_SIGNAL is defined).
> 
> Agreed.
> -Jim
> 
>> 
>> -- 
>> Joseph S. Myers
>> joseph at codesourcery.com
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20121004/cec1d0fe/attachment.html