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

[James W Thomas]

Begin forwarded message:

> From: James W Thomas <jaswthomas at sbcglobal.net>
> Subject: Re: (SC22WG14.13008) Comments on N1711 (PDTS 18661-1)
> Date: June 6, 2013 12:24:54 PM PDT
> To: "Joseph S. Meyers" <jsm at polyomino.org.uk>
> Cc: SC22 WG14 <sc22wg14 at open-std.org>
> 
> Since TS 18861-1 is in ballot, let's take any followup discussion about it offline.
> 
> -Jim
> 
> On Jun 6, 2013, at 10:12 AM, James W Thomas <jaswthomas at sbcglobal.net> wrote:
> 
>> Joseph,
>> 
>> Many thanks for the careful review and clear comments. Please see my initial responses below.
>> 
>> -Jim
>> 
>> On Jun 4, 2013, at 7:38 AM, Joseph S. Myers <jsm at polyomino.org.uk> wrote:
>> 
>>> 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.
>> 
>> How about " closed arithmetic system; also conversions between … auxiliary operations"?
>> 
>>> 
>>> Page vi:
>>> 
>>> Use an actual dash instead of two hyphens "--" (more than once on this
>>> page, maybe elsewhere).
>> 
>> agreed (only two instances in the document)
>> 
>>> 
>>> "defines it model" should be "defines its model".
>> 
>> agreed
>> 
>>> 
>>> 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.
>> 
>> Agreed. How about:
>> 
>> Append to the third sentence of 4#6:
>> 
>> The strictly conforming programs that shall be accepted by a conforming freestanding implementation that defines __STDC_IEC_60559_BFP__ may also use features in the contents of the standard headers <fenv.h> and <math.h> and the numeric conversion functions (7.22.1) of the standard header <stdlib.h>.
>> 
>> or
>> 
>> A conforming freestanding implementation that defines __STDC_IEC_60559_BFP__ shall accept any strictly conforming program that does not use complex types and in which the use of the features specified in the library clause (clause 7) is confined to the contents of the standard headers <fenv.h>, <float.h>, <iso646.h>, <limits.h>, <math.h>, <stdalign.h>, <stdarg.h>, <stdbool.h>, <stddef.h>, <stdint.h>, and <stdnoreturn.h> and the numeric conversion functions (7.22.1) of the standard header <stdlib.h>.
>>     
>>> 
>>> 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.
>> 
>> This issue was presented at the Oct 2012 WG 14 meeting in Portland, where the response (without objection) was "keep it simple".
>> 
>>> 
>>> 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.
>> 
>> Agreed. I believe the intention was for the leading "%" to be included and ".*" to be excluded.
>> 
>>> 
>>> 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.
>> 
>> The strfrom functions are intended to be stripped down versions of snprintf, for clarity of specification and ease of implementation. I'd worry about specifying an idea of what snprintf should be, without clear committee direction.
>> 
>>> 
>>> 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.
>> 
>> If an encoding error can't occur for these numeric conversions, then we should be able to omit that part of the specification.
>> 
>>> 
>>> 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.
>> 
>> agreed
>> 
>>> 
>>> 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.
>> 
>> I believe the intended meaning will be understood, but we could add a footnote saying the "The function groups include the functions for all supported types, for example, acosf and acosl, as all as acos."
>> 
>>> 
>>> The table of function groups affected by constant rounding modes
>>> should include hypot.
>> 
>> agreed
>> 
>>> 
>>> 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.
>> 
>> As a general rule, which ISO documents (other than the C Standard) should a TS or TR specify changes to? This could become quite a burden.
>> 
>>> 
>>> 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.
>> 
>> How about "all floating-point operators, implicit conversions (including the conversion of a value represented in a format wider than its semantic types to its semantic type, as done by classification macros), and invocations of functions …"? Is the parenthetical part helpful?
>> 
>>> 
>>> Page 19:
>>> 
>>> Change "The unordered macro" to "The isunordered macro".
>> 
>> agreed
>> 
>>> 
>>> 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.
>> 
>> agreed
>> 
>>> 
>>> The width macros for intmax_t and uintmax_t should go in <stdint.h>
>>> (7.20.2.5), not <limits.h>.
>> 
>> agreed
>> 
>>> 
>>> 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.
>> 
>> agreed
>> 
>>> 
>>> Page 27:
>>> 
>>> Specify that the new FP_INT_* macros expand to integer constant
>>> expressions with distinct values.
>> 
>> agreed
>> 
>>> 
>>> "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.".
>> 
>> Sigh. So a domain error might occur even if the rounded integral value is in the range of the type for a given width macro - if the implementation has integer types with the same width but different ranges. Are there such implementations? I agree the specification should accommodate the possibility.
>> .
>> 
>>> 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".
>> 
>> The change in F.2.1#3 says "This annex [F] uses the term NaN, unless explicitly qualified, to denote quiet NaNs".
>>    
>>> 
>>> 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.
>> 
>> These functions must not raise any floating-point exceptions, but it appears we haven't said that.
>> 
>>> 
>>> -- 
>>> Joseph S. Myers
>>> joseph at codesourcery.com
>> 
> 

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