[Cfp-interest] Fwd: (SC22WG14.13008) Comments on N1711 (PDTS 18661-1)

Tue Jun 4 09:55:58 PDT 2013

Begin forwarded message:

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

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