<span style=" font-size:10pt;font-family:sans-serif">I think this pretty
much accurately reflects my position as well and was what I intended to
state in the next WG14 meeting.</span><br><br><span style=" font-size:10pt;font-family:sans-serif">Regards,<br><br>Rajan Bhakta<br>z/OS XL C/C++ Compiler Technical Architect<br>ISO C Standards Representative for Canada, PL22.11 Chair (USA)<br>C Compiler Development<br>Contact: rbhakta@us.ibm.com, Rajan Bhakta/Houston/IBM</span><br><br><br><br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">From:
</span><span style=" font-size:9pt;font-family:sans-serif">Jim
Thomas <jaswthomas@sbcglobal.net></span><br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">To:
</span><span style=" font-size:9pt;font-family:sans-serif">CFP
<cfp-interest@ucbtest.org></span><br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">Date:
</span><span style=" font-size:9pt;font-family:sans-serif">07/14/2019
04:48 PM</span><br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">Subject:
</span><span style=" font-size:9pt;font-family:sans-serif">[EXTERNAL]
[Cfp-interest 1349] Re: (SC22WG14.16713) N2380: printf of NaN()</span><br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">Sent
by: </span><span style=" font-size:9pt;font-family:sans-serif">cfp-interest-bounces@oakapple.net</span><br><hr noshade><br><br><br><tt><span style=" font-size:10pt">I’ve interleaved some comments for
discussion at the July CFP meeting. Note that these comments have not been
sent to WG14 or to the WG14 members on the thread.<br><br>- Jim Thomas<br><br>> On May 15, 2019, at 8:28 AM, Martin Sebor <msebor@gmail.com>
wrote:<br>> <br>> On 5/15/19 3:37 AM, Jens Gustedt wrote:<br>>> Hello JF,<br>>> On Tue, 14 May 2019 12:33:24 -0700 JF Bastien <cxx@jfbastien.com>
wrote:<br>>>> Specifically, I think C should instead support:<br>>>> <br>>>> 1. Extraction of NaN integer payload from double / float /
long<br>>>> double. 2. Creation of NaN with integer payload (without going<br>>>> through character sequences).<br>>> C in its current flux has this already in Annex F, `getpayload`
and<br>>> `setpayload`. Would you want them to be mandatory?<br>>>> The specification of NaN-related *n-char-sequence* should
then be<br>>>> constrained to match the restrictions imposed on integer payloads<br>>>> (i.e. must be positive, maximum value).<br>>>> <br>>>> I'd then like to understand what encodings must be supported:
does the<br>>>> integral encoding support decimal only, or does it support<br>>>> hexadecimal (and must it be preceded by 0x)? I think this<br>>>> determination should be made by surveying existing implementations.<br>>>> <br>>>> Then, and only then, does it make sense to figure out the
maximum<br>>>> number of characters of NaN-related *n-char-sequence* as proposed
by<br>>>> N2380.<br>>> I can't follow you here. This macro is intended to provide the<br>>> knowledge to the user how large a buffer should be if they are<br>>> expecting that a NaN could be printed. This makes sense to me<br>>> regardless what the encodings could be. The user here is just
at the<br>>> receiving end and tries to deal with buffer overflows.<br><br>IEC 60559 does not attach any semantics to NaN payloads, beyond recommending
propagation rules. It notes that implementations might encode diagnostic
information in payloads. There have been various ideas about how to do
that, and some of the ideas have been implemented. There has been no use
of payload inspiring enough to suggest that further standard specification
would be more valuable than implementations’ flexibility to have their
own meaning, if any, for payloads. Thus, payloads are intentionally minimally
specified, and hence non-portable. The printf specification for NaNs is
intended to serve both implementations that do and ones that do not attach
meaning to payloads.<br><br>> FWIW, the macro is just a band aid on a small subset of<br>> the problem described in N2301:<br>> <br>> 1) there is no requirement/guarantee that the printf output<br>> is the same even for the same representation of a NaN<br><br>Implementations should be free to print whatever seems appropriate for
any meaning they give payloads. <br><br>Or is the “problem" referring to behavior on one implementation?
For implementations that do not conform to Annex F, is there a requirement
that printf output be the same for the same representation of a number?
For Annex F, such a requirement (for consistency on a given implementation),
seems ok, though of uncertain value.<br><br>> <br>> 2) there is no guarantee that what printf outputs for a NaN<br>> can be parsed by scanf to get the same NaN back<br><br>What does this mean? There’s no 1-1 correspondence between NaNs and their
I/O string representations. <br><br>Implementations that attach no meaning to NaNs should print (-)nan or maybe
(-)nan(), but they need to scan printf output from other systems.<br><br>> <br>> 3) there is no limit on the amount of output for a NaN<br><br>Right. This is an unnecessary risk.<br>> <br>> 4) there is no way for printf callers to choose which of<br>> the two forms of NaN to format, so no portability<br><br>Payloads aren’t portable. It would help portability if the user could
ask for the (-)nan form. With the (-)nan(n-char-sequence) form, there can
be no expectation of implementation-independent printf output. A user option
to get the nan(n-char-sequence) form can’t determine the n-char-sequence,
so it would only serve to get nan() instead of nan.<br><br>- Jim Thomas<br><br>> <br>> When we discussed N2301 there was 12/0/1 consensus to address<br>> "the issue" in the paper. All of the above is "the
issue."<br>> <br>> The group then started bike-shedding how "the issue" should<br>> be addressed and someone had the bright idea that precision<br>> would be a better way to do it then the pound AKA hash flag<br>> in the proposal. A straw poll of that idea was 7/4/3, which<br>> by our arbitrary standards of interpretation was viewed as<br>> direction to proceed. But precision isn't a viable mechanism<br>> for selecting between the NaN formats because it would screw<br>> up the formatting of finite numbers. So with that, "the
issue"<br>> has morphed into just (3) above which is the subset N2380 tries<br>> to solve. In practice (3) isn't a real problem because no sane<br>> implementation would produce more output than the number of bits<br>> in a NaN, so a portable program can conservatively allocate at<br>> least that much space for each number and be assured it won't<br>> overflow. Unlike (3), though, all the others aspects of<br>> the issue are real or at least far more likely. N2301 solved<br>> all of them, including (3). But in our wisdom, we choose to<br>> solve the part that doesn't affect anyone and call it good.<br>> <br>> Martin<br><br><br>_______________________________________________<br>Cfp-interest mailing list<br>Cfp-interest@oakapple.net<br></span></tt><a href="http://mailman.oakapple.net/mailman/listinfo/cfp-interest"><tt><span style=" font-size:10pt">http://mailman.oakapple.net/mailman/listinfo/cfp-interest</span></tt></a><tt><span style=" font-size:10pt"><br><br></span></tt><br><br><BR>