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