<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Looks like the Cc to CFP didn't work, so I'm forwarding this separately.<div><br></div><div>-Jim<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: [Cfp-interest] (SC22WG14.12843) CFP teleconference, documents</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;">March 7, 2013 11:53:57 AM PST<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;">CFP <<a href="mailto:cfp-interest@ucbtest.org">cfp-interest@ucbtest.org</a>>, 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 excellent comments. They will be a big help in filing out the issues list for this relatively new and still incomplete specification. Please see partial responses below.<br><br>-Jim<br><br>On Mar 6, 2013, at 2:36 PM, Joseph S. Myers <<a href="mailto:jsm@polyomino.org.uk">jsm@polyomino.org.uk</a>> wrote:<br><br><blockquote type="cite">Some comments on the part 3 document (interchange and extended types, <br>N1680) (page numbers are those printed on the pages):<br><br><br>Types (pages 3-5):<br><br>Is a data interchange type on which not all operations are supported an <br>arithmetic type or a floating type? Presumably not, because the <br>definitions of "floating types" (C11 6.2.5#11) and "arithmetic types (#18) <br>still apply. <br></blockquote><br>Right - such data-interchange types are not arithmetic types or floating types.<br><br><blockquote type="cite">So which operations are supported for such a type can be <br>determined by the existing wording in C11, together with the addition text <br>this document adds regarding conversions. But there are some issues for <br>which this isn't sufficient:<br><br>* Is such a type a scalar type? To meet the constraints for casts, for <br>example (6.5.4#2), it appears these types should be scalar types, and the <br>wording added as 6.3.2.3a (page 8) certainly suggests conversions <br>involving such types should be allowed. Similarly, the wording about <br>sequencing of side-effects (6.5#2) is something that ought to apply to <br>such types; likewise the wording on initializers for scalars (6.7.9#11). <br>But I don't see any change to the definition of scalar types (6.2.5#21) to <br>include data interchange types that are not arithmetic types.<br><br>* However, several places assume that scalars can be compared with 0 <br>(unary !, &&, ||, ?:, selection and iteration statements, assert macro). <br>So if you do make these types scalar types, then you need either to allow <br>such comparisons for them (given that such types, not being arithmetic, do <br>*not* meet the constraints for == and !=), or make exceptions in those <br>places.<br></blockquote><br>Good issue. I don't think we want data-interchange types to be scalar types. We can try including data-interchange types just where needed. For example, for casts we could change 6.2.5 to:<br><br>…<br>[2] <span class="Apple-tab-span" style="white-space:pre"> </span>Unless the type name specifies a void type, the type name shall specify atomic, qualified, or unqualified scalar or data-interchange type, and the operand shall have scalar or data-interchange type.<br>…<br>[4]<span class="Apple-tab-span" style="white-space:pre"> </span>A pointer type shall not be converted to any floating or data-interchange type. A floating or data-interchange type shall not be converted to any pointer type.<br>…<br><br><blockquote type="cite"><br>* The rules for default static initialization (6.7.9#10) cover pointers, <br>arithmetic types, aggregates and unions. So with such a type not being <br>arithmetic, you need to define static initialization, presumably to <br>positive zero.<br></blockquote><br>Right. Work needed there.<br><br><blockquote type="cite"><br>Then there are some other issues where the definition of both data <br>interchange types (whether or not interchange floating types) and extended <br>floating types is incomplete:<br><br>* Where are the syntax additions for the new types? Should _FloatN, <br>_FloatNx, _DecimalN, _DecimalNx, for values of N supported by the <br>implementation, be keywords added to the list in 6.4.1#1? They certainly <br>need to be matched by the type-specifier syntax (6.7.2#1). And <br>appropriate combinations of specifiers (allowing _Complex or _Imaginary) <br>need to be added to the list of valid combinations in 6.7.2#2.<br></blockquote><br>To be done.<br><br><blockquote type="cite"><br>* I'm not sure of the logic of supporting _Complex only with interchange <br>floating types; should implementations be permitted also to support it <br>with (binary) data interchange types that aren't interchange floating <br>types, and with (binary) extended floating types? Likewise _Imaginary.<br></blockquote><br>The data-iinterchange types and their conversion operations we have now are intended to support the exchange of complex and imaginary data, which is fully specified by its real components.<br><br>We might want to reconsider adding extended complex and imaginary types. Otherwise one must leave the complex domain to fully use extended formats for wide evaluation.<br><br><blockquote type="cite"><br>* There are references to such things as _Float32 being equivalent to <br>float. What does "equivalent" mean here? The types could be the same <br>type (like "long" and "long int"). They could be compatible types (like <br>"int" and an enum for which the implementation-defined compatible integer <br>type is int), but not the same. They could be distinct (like "char" and <br>"unsigned char", even if char is unsigned) but have the same <br>representation and alignment. Or one might imagine float having one <br>endianness and _Float32 the other (both being binary32); is that intended <br>to be ruled out?<br></blockquote><br><blockquote type="cite"><br>If various possibilities for whether types are the same / compatible / <br>distinct but with the same values and (apart maybe from bit ordering) <br>representation are intended to be allowed, I think the TS should make <br>clear exactly what possibilities are permitted, rather than just using a <br>vague "equivalent".<br></blockquote><br>Their being the same type seems most direct. A possible problem is that this might allow more mixing of type nomenclatures and result in more confusing code. Also, if double and _Float64 were the same type and long double and _Float64 were the same type, then double and long double would be the same type, though they aren't.<br><br><blockquote type="cite"><br>* The default argument promotions promote float to double when passed in <br>variable arguments (6.5.2.2#6). Is such promotion permitted or required <br>for _Float32 (clearly it is if _Float32 is actually the same type as <br>float)? What about for _Float16? An application wishing to retrieve such <br>a value with va_arg needs to know the promoted type, since va_arg must be <br>called with the promoted type name (C11 7.16.1.1#2).<br></blockquote><br>Yes, it needs to be specified.<br><br><blockquote type="cite"><br>* Are all the new types basic / fundamental types, so that malloc must <br>return memory suitably aligned for them (see my reflector message 12832 on <br>9 Jan for more on the issues there)? C11 6.2.5#14 says "The type char, <br>the signed and unsigned integer types, and the floating types are <br>collectively called the basic types.", leaving open the question of <br>whether data interchange types are also basic types.<br></blockquote><br>Issue: how to assure that malloc can handle data-interchange types.<br><br><blockquote type="cite"><br><br>Characteristics (pages 5-7):<br><br>* Must the value of DECIMAL_DIG be correct for all the new _FloatN and <br>_FloatNx types (floating integer types and extended floating types, not <br>ones that are only data interchange types), or just for float, double and <br>long double?<br></blockquote><br>Since there are strto functions for all the binary data-interchange and extended types, DECIMAL_DIG should be large enough for them too. Words needed.<br><br><blockquote type="cite"><br><br>Conversions (pages 7-8):<br><br>* You say "Otherwise, if both operands are floating types and the sets of <br>values of their corresponding real types are equivalent, no further <br>conversion is needed.". That is, the resulting type is left unspecified <br>if for example the operands are float and _Float32 but those are distinct <br>types. I'd think it would be better to follow the practice for integer <br>types, where if two types have the same values the result is determined by <br>integer conversion rank, and require an implementation-defined total order <br>on real floating types with the same set of values (or completely define <br>such an order in this document rather than leaving it <br>implementation-defined).<br></blockquote><br>Good issue.<br><br><blockquote type="cite"><br><br>Mathematics <math.h> (pages 9-18):<br><br>* If an implementation doesn't support _Float128, say, are the function <br>and macro names associated with it still reserved for the implementation? <br>I'd say that they should be (and much the same applies to <float.h> macros <br>when <float.h> is included) - that might facilitate, for example, <br>implementations with full support for _Float32 and _Float64 but only <br>partial _Float128 support. So it should be made clear what is reserved. <br>(I'd guess acosf256 is reserved but not acosf257, because of the rules on <br>which N have a _FloatN format defined.)<br></blockquote><br>Yes, they should be reserved. Not acosf257.<br><br><blockquote type="cite"><br>* The statement on page 10 about SNANFN and SNANDN macros appears to be <br>the first use of the term "interface type". This should probably be "data <br>interchange type". <br></blockquote><br>Right.<br><br><blockquote type="cite">But then for FP_FAST_FMAMFN and FP_FAST_FMADN you <br>introduce "interface floating type" - I guess this should be "interchange <br>floating type".<br></blockquote><br>Right.<br><br><blockquote type="cite"><br><br>Numeric conversion functions <stdlib.h> (pages 18-19):<br><br>* There are two references to __STDC_WANT_IEC_00000_EXT3__ that should use <br>the 18661 number.<br></blockquote><br>Yes.<br><br><blockquote type="cite"><br>* Should there be wide-string analogues of these conversion functions <br>(analogues of wcstod / swprintf_s for the new types)?<br></blockquote><br>Issue. I believe these were discussed but haven't found the rationale for omitting them.<br><br><blockquote type="cite"><br><br>Other:<br><br>* You define some new complex types, but no associated <complex.h> <br>functions. Should names for such functions such as cacosfN at least be <br>reserved to the implementation? (And likewise for the future library <br>directions <complex.h> functions listed in 7.31.1#1.)<br></blockquote><br>Yes, these are needed.<br><br><blockquote type="cite"><br>* Should <tgmath.h> be required to handle the new interchange floating <br>types and extended floating types? (At least for real arguments, if you <br>don't define corresponding complex functions for the new types.) <br>Certainly part 2 extends it to cover decimal types.<br></blockquote><br>Yes, not done yet.<br><br><blockquote type="cite"><br>-- <br>Joseph S. Myers<br><a href="mailto:joseph@codesourcery.com">joseph@codesourcery.com</a><br></blockquote><br><br>_______________________________________________<br>Cfp-interest mailing list<br><a href="mailto:Cfp-interest@oakapple.net">Cfp-interest@oakapple.net</a><br>http://mailman.oakapple.net/mailman/listinfo/cfp-interest<br></div></blockquote></div><br></div></body></html>