<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><br><div>Begin forwarded message:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family:'Helvetica'; font-size:medium; color:rgba(0, 0, 0, 1.0);"><b>From: </b></span><span style="font-family:'Helvetica'; font-size:medium;">"Joseph S. Myers" <<a href="mailto:jsm@polyomino.org.uk">jsm@polyomino.org.uk</a>><br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family:'Helvetica'; font-size:medium; color:rgba(0, 0, 0, 1.0);"><b>Subject: </b></span><span style="font-family:'Helvetica'; font-size:medium;"><b>(SC22WG14.13008) Comments on N1711 (PDTS 18661-1)</b><br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family:'Helvetica'; font-size:medium; color:rgba(0, 0, 0, 1.0);"><b>Date: </b></span><span style="font-family:'Helvetica'; font-size:medium;">June 4, 2013 7:38:38 AM PDT<br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family:'Helvetica'; font-size:medium; color:rgba(0, 0, 0, 1.0);"><b>To: </b></span><span style="font-family:'Helvetica'; font-size:medium;"><a href="mailto:sc22wg14@open-std.org">sc22wg14@open-std.org</a><br></span></div><br><div>The following are my draft comments from having reviewed the N1711<br>draft of TS 18661-1. Some or all of these may appear later in some<br>form in UK ballot comments, but are sent now for information.<br><br>Page v:<br><br>The description of operations in IEC 60559:1989 starts a new sentence<br>in parentheses without any punctuation terminating what came before<br>("system (It ... operations.)"). Consistency with the lack of<br>sentence-ending punctuation in the other points in this list suggests<br>it might be better to say "system; it ... operations", using a<br>semicolon instead of parentheses and avoiding the capital "I" and the<br>terminating "." presently inside the parentheses.<br><br>Page vi:<br><br>Use an actual dash instead of two hyphens "--" (more than once on this<br>page, maybe elsewhere).<br><br>"defines it model" should be "defines its model".<br><br>Page 2:<br><br>Although, formally, the effects of this document's changes to C11 are<br>irrelevant to implementations not defining __STDC_IEC_60559_BFP__ and<br>implementing Annex F, it still seems appropriate for such changes to<br>avoid placing undue burdens on implementations not defining<br>__STDC_IEC_60559_BFP__ and implementing Annex F, if incorporated<br>verbatim in a future revision of the C standard. With that in mind,<br>requiring additional library support (especially the full contents of<br><math.h>) from a conforming freestanding implementation not claiming<br>to support Annex F seems inappropriate. Instead, the additions to 4#6<br>should be phrased in a form that only requires any additional library<br>support when __STDC_IEC_60559_BFP__ is defined.<br><br>Page 3:<br><br>(As previously noted on 25 Sep 2012:)<br><br>__STDC_WANT_IEC_18661_EXT1__ should be handled consistently with other<br>__STDC_WANT_* macros. That is, following the wording from C11 K.3.1.1<br>paragraphs 1-4 (but with the new declarations not being present if the<br>macro is not defined). The requirement for being identically defined<br>for all header inclusions should probably be for all headers that are<br>modified by this TS part (<fenv.h> <limits.h> <math.h> <stdint.h><br><stdlib.h> <tgmath.h>).<br><br>All subsequent places in the document that show a #define of this<br>macro then need to change to #define it to 1 instead of to empty.<br><br>Page 12:<br><br>The specification of the new strfrom* functions seems unclear about<br>the format string contents. Taken literally, the string contains<br>optionally ".", ".*" or ".<decimal-integer>", followed by one of the<br>given letters, but not a leading "%". However the equivalence to<br>snprintf rather suggests a leading "%" should be included. And the<br>absence of any way to provide an "int" field for ".*" precision<br>suggests that case should not be allowed here. So the text here needs<br>reworking to make clearer exactly what strings are allowed.<br><br>Also, it seems unfortunate to repeat the deficiency of snprintf that<br>behavior is undefined if the number of characters that would be<br>written exceeds INT_MAX. Making the return type size_t, with SIZE_MAX<br>as error return, would avoid that issue.<br><br>Also, the error condition given is "if an encoding error occurred",<br>but that condition doesn't seem applicable to these numeric<br>conversions. So maybe it should be "if an error occurred", without<br>being specific about error conditions. Or the possibility of an error<br>and the special return value for an error could be eliminated<br>completely.<br><br>Page 15:<br><br>The new 7.6.1a paragraph 4 says "the mode specified by the dynamic<br>floating-point environment, which is the dynamic rounding mode that<br>was established either at thread creation or by a call to fesetround,<br>fesetenv, or feupdateenv". But the new function fesetmode can also<br>have the effect of changing the dynamic rounding mode, so should be<br>included in that list.<br><br>The definition of functions affected by constant rounding modes should<br>be more explicit that the float and long double versions of functions<br>listed are also included.<br><br>The table of function groups affected by constant rounding modes<br>should include hypot.<br><br>For implementations of ISO 24747, the additional functions defined<br>there should, by analogy with the C11 <math.h> functions, also be<br>affected by constant rounding modes.<br><br>The reference to "all floating-point operators and invocations of<br>functions indicated in Table 2 below, for which macro replacement has<br>not been suppressed" isn't clear about implicit conversions, which are<br>neither operators nor function invocations. I think both explicit and<br>implicit conversions, including a conversion of a value represented in<br>a format wider than its semantic type to its semantic type (as is done<br>by classification macros, for example), should be explicitly mentioned<br>as being governed by the constant rounding mode.<br><br>Page 19:<br><br>Change "The unordered macro" to "The isunordered macro".<br><br>Page 23:<br><br>The width macros should probably not be required to have the same type<br>as the type whose width they describe. That is, they should be added<br>to the "except for CHAR_BIT and MB_LEN_MAX" clause in 5.2.4.2.1. A<br>similar amendment needs making to 7.20.2#2 to avoid spurious<br>requirements on the types of the <stdint.h> width macros.<br><br>The width macros for intmax_t and uintmax_t should go in <stdint.h><br>(7.20.2.5), not <limits.h>.<br><br>Page 24:<br><br>For consistency, width macros should be provided for all the types for<br>which limit macros are provided in <stdint.h>. I think this includes<br>the exact-width types (after all, the limit macros are provided for<br>those types, though the values are always known). It certainly<br>includes intptr_t, uintptr_t, ptrdiff_t, sig_atomic_t, size_t, wchar_t<br>and wint_t.<br><br>Page 27:<br><br>Specify that the new FP_INT_* macros expand to integer constant<br>expressions with distinct values.<br><br>"outside the range of integers of the specified width" assumes there<br>is a single range for integer types of that width, which is not<br>otherwise required by ISO C; append "for any integer representation<br>supported by the implementation", with a footnote "For signed types,<br>6.2.6.2 permits three representations, which differ in whether a value<br>of -(2^M) can be represented.".<br><br>Page 28:<br><br>Make the same change where the same wording appears twice here.<br><br>Page 31:<br><br>Explicitly say "just one argument is a quiet NaN" instead of "just one<br>argument is a NaN".<br><br>Page 41:<br><br>It seems unclear if the setpayload / setpayloadsig functions are<br>permitted to raise the "invalid" exception if the specified payload<br>value is a signaling NaN.<br><br>-- <br>Joseph S. Myers<br><a href="mailto:joseph@codesourcery.com">joseph@codesourcery.com</a><br></div></blockquote></div><br></body></html>