[Cfp-interest] Fwd: (SC22WG14.12719) Observations on N1631

[Jim Thomas]

Begin forwarded message:

> From: Jim Thomas <jaswthomas at sbcglobal.net>
> Subject: Re: (SC22WG14.12719) Observations on N1631
> Date: September 25, 2012 3:55:36 PM PDT
> To: "Joseph S. Myers" <jsm at polyomino.org.uk>
> Cc: SC22 WG14 <sc22wg14 at open-std.org>
> 
> Joseph,
> 
> Thank you for the careful reading and thoughtful comments. Please see initial responses below.
> 
> -Jim
> 
> -On Sep 25, 2012, at 2:33 PM, Joseph S. Myers wrote:
> 
>> Here are some observations on the floating-point draft N1631 in the 
>> pre-Portland mailing:
>> 
>> Page iv, line 22, "ISO/IEC 9899 11" should be "ISO/IEC 9899:2011".
> 
> Right
> 
>> 
>> Page 1: regarding __STDC_WANT_IEC_60559_BFP__, should the same rules as in 
>> C11 Annex K be applied regarding requiring the macro to have the same 
>> definition for all inclusions of relevant headers, and allowing a 
>> definition of 0 to mean that the relevant functions / macros are not 
>> defined?  (__STDC_WANT_MATH_SPEC_FUNCS__ appears to be like that as well.)  
>> I don't think it's a good idea to have different __STDC_WANT_* macros 
>> behave differently from each other in this regard (in turn, __STDC_WANT_* 
>> unfortunately behave differently from the working of POSIX's 
>> _POSIX_C_SOURCE, which must be defined before *any* system header is 
>> included).
> 
> Agreed - WANT macros in C should be consistent.
> 
>> 
>> Page 4: regarding canonical encodings, is the property of being canonical 
>> considered to be one of the full sizeof (floating-type) bytes of the 
>> object, or one excluding padding bits?  For example, if long double is x86 
>> extended, with 10 significant bytes, but sizeof (long double) is 12 or 16, 
>> including some tail padding, must canonical values be defined for the 
>> padding?  (I don't think doing so really makes sense - there is no 
>> requirement for implementations to preserve padding bits, or copy them 
>> when copying a value, and a value stored in registers may not have them, 
>> so it's hardly meaningful to say they take on particular values for a call 
>> to iscanonical.  But I'm not sure how you define, in a generic way, what 
>> noncanonical aspects of the encoding must be preserved, which would seem 
>> necessary for iscanonical on a value to make sense.)
> 
> Canonical is intended to be a property of the value bits, not any padding bits. I don't understand your last point.
> 
>> 
>> Page 23: you have some functions in math.h whose types involve intmax_t 
>> and uintmax_t.  Is this like the use of va_list in stdio.h - the type must 
>> be the same as the type used for intmax_t in stdint.h, but math.h must not 
>> actually use the identifier intmax_t because it's not reserved by that 
>> header?  Or should math.h actually define these types, with the same 
>> definitions as in stdint.h?
> 
> Not sure which approach is better. We'll look into it.
> 
>> 
>> Also regarding those *fromfp* functions: I don't think there is actually a 
>> C requirement that all signed integer types of the same width represent 
>> the same values; I think it might be permitted for some such types to 
>> represent -(2^N) as their least value and others to have -(2^N - 1) as 
>> their least value.  It may be appropriate to prohibit such strange 
>> implementations.
> 
> I would have guessed this was disallowed, else would cause problems in conversions.
> 
>> 
>> Must the "unspecified value" returned in certain cases be within the range 
>> of a type of the given width?
> 
> No. We considered this restriction but didn't see a practical reason for it.
> 
>> 
>> When 0 is returned for a width given as 0, do the other requirements still 
>> apply that if the rounded result is not 0, that is a domain error (and, as 
>> applicable, inexact)?
> 
> This does look like an awkward edge case in the spec. We'll look at it again.
> 
> 
>> 
>> -- 
>> Joseph S. Myers
>> joseph at codesourcery.com
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20120925/87da3e0f/attachment.html