[Cfp-interest] signaling NaN I/O issue?

[Rajan Bhakta]

Hi Jim,

I agree with the idea that signalling NaNs should not just go away, I was 
just having an issue with specifically singling out the stdio functions 
for this particular statement. Just the general statement "Functions that 
don't signal on signaling 
NaN inputs need to return a signaling NaN.
" should suffice. I understand we want to clarify what it means for printf 
and printing a sNaN, but my point was not to special case the stdio 
functions by pointing them out as something special. i.e. in the case of 
printf, it has to return an integer with the value of the number of 
characters printed and so it cannot return a sNaN and hence is forced to 
signal. I understand the need to say what to print out however and that 
would be the only thing to special case as it is actually a special case 
due to the functionality of the function, not the signalling aspect.

In the end however I am not strongly objecting to this, I just wanted to 
bring out an observation I thought was interesting and worth noting.

Regards,

Rajan Bhakta
z/OS XL C/C++ Compiler Technical Architect
ISO C Standards Representative for Canada
C Compiler Development
Contact: rbhakta at ca.ibm.com, Rajan Bhakta/Toronto/IBM
Telephone: (905) 413-3995



From:
Jim Thomas <jwthomas at cup.hp.com>
To:
Rajan Bhakta/Toronto/IBM at IBMCA
Cc:
"cfp-interest at ucbtest.org" <cfp-interest at ucbtest.org>
Date:
05/06/2011 11:28 AM
Subject:
Re: signaling NaN I/O issue?



Rajan,

Thanks for the clarification. Functions that don't signal on signaling 
NaN inputs need to return a signaling NaN. Signaling NaNs shouldn't 
quietly go away. Printf can't return a character string representation 
of a signaling NaN, because there isn't one.

-Jim

Rajan Bhakta wrote:

>
> Hi Jim,
>
> I was saying that the fact that given we do not yet require functions 
> to signal when passed in a sNAN, why are we making the stdio family of 
> functions a special case in that they must signal and convert the 
> argument to a qNAN? I don't think that special casing certain library 
> functions is a good idea due to the precedent it would set.
>
> Regards,
>
> Rajan Bhakta
> z/OS XL C/C++ Compiler Technical Architect
> ISO C Standards Representative for Canada
> C Compiler Development
> Contact: rbhakta at ca.ibm.com, Rajan Bhakta/Toronto/IBM
> Telephone: (905) 413-3995
>
>
> From:                  Jim Thomas <jwthomas at cup.hp.com>
> To:            Rajan Bhakta/Toronto/IBM at IBMCA
> Cc:            "cfp-interest at ucbtest.org" <cfp-interest at ucbtest.org>
> Date:                  05/05/2011 06:06 PM
> Subject:               signaling NaN I/O issue?
>
>
> ------------------------------------------------------------------------
>
>
>
> Hi Rajan,
>
> Just before leaving the teleconference this morning you commented on the
> last item in Fred's paper (re 7.21.1). Afterwards we weren't sure we'd
> understood your point. Please clarify.
>
> -Jim
>
>



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