<br><font size=2 face="sans-serif">Hi Jim,</font>
<br>
<br><font size=2 face="sans-serif">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 "</font><tt><font size=2>Functions that don't signal
on signaling <br>
NaN inputs need to return a signaling NaN.</font></tt>
<br><font size=2 face="sans-serif">" 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.</font>
<br>
<br><font size=2 face="sans-serif">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.</font>
<br>
<br><font size=2 face="sans-serif">Regards,<br>
<br>
Rajan Bhakta<br>
z/OS XL C/C++ Compiler Technical Architect<br>
ISO C Standards Representative for Canada<br>
C Compiler Development<br>
Contact: rbhakta@ca.ibm.com, Rajan Bhakta/Toronto/IBM<br>
Telephone: (905) 413-3995</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td><font size=1 color=#5f5f5f face="sans-serif">From:</font>
<td><font size=1 face="sans-serif">Jim Thomas <jwthomas@cup.hp.com></font>
<tr valign=top>
<td><font size=1 color=#5f5f5f face="sans-serif">To:</font>
<td><font size=1 face="sans-serif">Rajan Bhakta/Toronto/IBM@IBMCA</font>
<tr>
<td valign=top><font size=1 color=#5f5f5f face="sans-serif">Cc:</font>
<td><font size=1 face="sans-serif">"cfp-interest@ucbtest.org"
<cfp-interest@ucbtest.org></font>
<tr valign=top>
<td><font size=1 color=#5f5f5f face="sans-serif">Date:</font>
<td><font size=1 face="sans-serif">05/06/2011 11:28 AM</font>
<tr valign=top>
<td><font size=1 color=#5f5f5f face="sans-serif">Subject:</font>
<td><font size=1 face="sans-serif">Re: signaling NaN I/O issue?</font></table>
<br>
<hr noshade>
<br>
<br>
<br><tt><font size=2>Rajan,<br>
<br>
Thanks for the clarification. Functions that don't signal on signaling
<br>
NaN inputs need to return a signaling NaN. Signaling NaNs shouldn't <br>
quietly go away. Printf can't return a character string representation
<br>
of a signaling NaN, because there isn't one.<br>
<br>
-Jim<br>
<br>
Rajan Bhakta wrote:<br>
<br>
><br>
> Hi Jim,<br>
><br>
> I was saying that the fact that given we do not yet require functions
<br>
> to signal when passed in a sNAN, why are we making the stdio family
of <br>
> functions a special case in that they must signal and convert the
<br>
> argument to a qNAN? I don't think that special casing certain library
<br>
> functions is a good idea due to the precedent it would set.<br>
><br>
> Regards,<br>
><br>
> Rajan Bhakta<br>
> z/OS XL C/C++ Compiler Technical Architect<br>
> ISO C Standards Representative for Canada<br>
> C Compiler Development<br>
> Contact: rbhakta@ca.ibm.com, Rajan Bhakta/Toronto/IBM<br>
> Telephone: (905) 413-3995<br>
><br>
><br>
> From:
Jim Thomas <jwthomas@cup.hp.com><br>
> To:
Rajan Bhakta/Toronto/IBM@IBMCA<br>
> Cc:
"cfp-interest@ucbtest.org" <cfp-interest@ucbtest.org><br>
> Date:
05/05/2011 06:06 PM<br>
> Subject:
signaling NaN I/O issue?<br>
><br>
><br>
> ------------------------------------------------------------------------<br>
><br>
><br>
><br>
> Hi Rajan,<br>
><br>
> Just before leaving the teleconference this morning you commented
on the<br>
> last item in Fred's paper (re 7.21.1). Afterwards we weren't sure
we'd<br>
> understood your point. Please clarify.<br>
><br>
> -Jim<br>
><br>
><br>
<br>
</font></tt>
<br>
<br>