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

[Jim Thomas]

I posted a draft that addresses most of the issues Joseph raised. Look for change bars. Also, please see editor's comments below about the issues. The draft also addresses comments from another email from Joseph. I'll send editor's comments for that separately.

-Jim

On Sep 25, 2012, at 3:55 PM, Jim Thomas wrote:

> 
> 
> 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

Fixed

>> 
>>> 
>>> 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.

Didn't fix this one yet. The spec for the WANT macro for Annex K is sufficiently more complicated than the one our WANT macro is superseding that I'd like to discuss this at our teleconference next week before changing the draft.

>> 
>>> 
>>> 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.

See Joseph's elaboration in separate email. I made changes intended to consistently use the C "representation" and "value" terminology.

>> 
>>> 
>>> 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.

I put in a fix that does not require adding [u]intmax_t to the math.h names.

>> 
>>> 
>>> 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.

I couldn't remember why we needed the special spec for width 0, so removed it (for your consideration).

>> 
>> 
>>> 
>>> -- 
>>> Joseph S. Myers
>>> joseph at codesourcery.com
>> 
> 

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