<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">I posted a <a href="http://wiki.edg.com/twiki/pub/CFP/WebHome/cfp1-20121003.pdf">draft</a> 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.<div><br></div><div>-Jim</div><div><br><div><div>On Sep 25, 2012, at 3:55 PM, Jim Thomas wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div 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></div></blockquote></div></div></blockquote><div><br></div>Fixed</div><div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><blockquote type="cite"><div><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></div></blockquote></div></div></blockquote><div><br></div>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.</div><div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><blockquote type="cite"><div><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></div></blockquote></div></div></blockquote><div><br></div>See Joseph's elaboration in separate email. I made changes intended to consistently use the C "representation" and "value" terminology.</div><div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><blockquote type="cite"><div><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></div></blockquote></div></div></blockquote><div><br></div><div>I put in a fix that does not require adding [u]intmax_t to the math.h names.</div><div><br></div><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><blockquote type="cite"><div><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></div></blockquote></div></div></blockquote><div><br></div>I couldn't remember why we needed the special spec for width 0, so removed it (for your consideration).</div><div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><blockquote type="cite"><div><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></div></blockquote></div><br></div></body></html>