<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.12723) 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 26, 2012 8:41:13 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 detailed discussion. You've pointed out an area of the IEC 60559 binding to C that needs more consideration.<br><br>IEC 60559 refers (in increasing level of specificity) to:<br><br>data = floating-point numbers including +-0, +-infinity, NaN<br>representations = (sign, exponent, significant) triples, +/-infinity, quiet NaN, signaling NaN<br>encodings = bit strings for representations (not to be confused with the DPD an BID encoding schemes)<br><br>Some representations have non-canonical encodings as well as a canonical encoding. Encodings here might be thought of as bit strings for C value bits. Thus the C object representation is a still further level of specificity.<br><br>C refers to values and object representations. To fit the IEC 60559 abstractions to the C model, I think the IEC 60559 encodings do need to be regarded as C values (as you suggest). Another argument for this approach is that NaN payloads appear only at the encoding level.<br><br>The study group needs to go carefully throughout he C standard to see if this interpretation is, or can be made, consistent.<br><br>-Jim<br><br>On Sep 25, 2012, at 4:33 PM, Joseph S. Myers wrote:<br><br><blockquote type="cite">On Tue, 25 Sep 2012, Jim Thomas wrote:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Page 4: regarding canonical encodings, is the property of being canonical <br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">considered to be one of the full sizeof (floating-type) bytes of the <br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">object, or one excluding padding bits? For example, if long double is x86 <br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">extended, with 10 significant bytes, but sizeof (long double) is 12 or 16, <br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">including some tail padding, must canonical values be defined for the <br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">padding? (I don't think doing so really makes sense - there is no <br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">requirement for implementations to preserve padding bits, or copy them <br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">when copying a value, and a value stored in registers may not have them, <br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">so it's hardly meaningful to say they take on particular values for a call <br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">to iscanonical. But I'm not sure how you define, in a generic way, what <br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">noncanonical aspects of the encoding must be preserved, which would seem <br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">necessary for iscanonical on a value to make sense.)<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Canonical is intended to be a property of the value bits, not any <br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">padding bits. I don't understand your last point.<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">C11 6.2.6.1 paragraph 8 describes the existing rules for values with <br></blockquote><blockquote type="cite">multiple representations:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"> Where an operator is applied to a value that has more than one object <br></blockquote><blockquote type="cite"> representation, which object representation is used shall not affect the <br></blockquote><blockquote type="cite"> value of the result.52) Where a value is stored in an object using a type <br></blockquote><blockquote type="cite"> that has more than one object representation for that value, it is <br></blockquote><blockquote type="cite"> unspecified which representation is used, but a trap representation shall<br></blockquote><blockquote type="cite"> not be generated.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">So, it's not meaningful to say that x+y has a particular representation <br></blockquote><blockquote type="cite">(canonical or noncanonical) from among those for a value; it has a value, <br></blockquote><blockquote type="cite">not a representation. Only if stored in an object does it get a <br></blockquote><blockquote type="cite">representation. If passed to a function, the value then gets stored in a <br></blockquote><blockquote type="cite">new object (the parameter to that function being an object inside that <br></blockquote><blockquote type="cite">function), possibly with a new representation. All this applies as much <br></blockquote><blockquote type="cite">to different representations using value bits, as to bits that are purely <br></blockquote><blockquote type="cite">padding bits.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">But the iscanonical macro is defined (page 31) to act on a value, as if <br></blockquote><blockquote type="cite">values rather than representations are canonical.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">The canonicalize functions are defined to work on representations, which <br></blockquote><blockquote type="cite">seems meaningful. The problem is if you define "canonical" to relate to <br></blockquote><blockquote type="cite">representations rather than values, but then expect to be able to query it <br></blockquote><blockquote type="cite">for a value rather than a representation with iscanonical. If you want <br></blockquote><blockquote type="cite">iscanonical as defined to work, I think the noncanonical forms need to be <br></blockquote><blockquote type="cite">defined somehow as different *values* in C terms, not just different <br></blockquote><blockquote type="cite">*representations*. Or define it to take a pointer so it can work on <br></blockquote><blockquote type="cite">representations - then you need to state explicitly the intent as regards <br></blockquote><blockquote type="cite">considering value bits but not padding bits.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">(There may also be trap representations in a floating-point type - <br></blockquote><blockquote type="cite">representations not corresponding to any value of that type. With <br></blockquote><blockquote type="cite">iscanonical taking a value, attempting to pass the value of an object with <br></blockquote><blockquote type="cite">such a representation to iscanonical would result in undefined behavior. <br></blockquote><blockquote type="cite">With it taking a pointer, I suppose you could define iscanonical to return <br></blockquote><blockquote type="cite">0 when passed a pointer to a trap representation, and the canonicalize <br></blockquote><blockquote type="cite">functions to return a nonzero value because there is no corresponding <br></blockquote><blockquote type="cite">canonical representation.)<br></blockquote><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>