[Cfp-interest] (SC22WG14.12843) CFP teleconference, documents

[Jim Thomas]

Joseph,

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.

-Jim

On Mar 6, 2013, at 2:36 PM, Joseph S. Myers <jsm at polyomino.org.uk> wrote:

> Some comments on the part 3 document (interchange and extended types, 
> N1680) (page numbers are those printed on the pages):
> 
> 
> Types (pages 3-5):
> 
> Is a data interchange type on which not all operations are supported an 
> arithmetic type or a floating type?  Presumably not, because the 
> definitions of "floating types" (C11 6.2.5#11) and "arithmetic types (#18) 
> still apply.  

Right - such data-interchange types are not arithmetic types or floating types.

> So which operations are supported for such a type can be 
> determined by the existing wording in C11, together with the addition text 
> this document adds regarding conversions.  But there are some issues for 
> which this isn't sufficient:
> 
> * Is such a type a scalar type?  To meet the constraints for casts, for 
> example (6.5.4#2), it appears these types should be scalar types, and the 
> wording added as 6.3.2.3a (page 8) certainly suggests conversions 
> involving such types should be allowed.  Similarly, the wording about 
> sequencing of side-effects (6.5#2) is something that ought to apply to 
> such types; likewise the wording on initializers for scalars (6.7.9#11).  
> But I don't see any change to the definition of scalar types (6.2.5#21) to 
> include data interchange types that are not arithmetic types.
> 
> * However, several places assume that scalars can be compared with 0 
> (unary !, &&, ||, ?:, selection and iteration statements, assert macro).  
> So if you do make these types scalar types, then you need either to allow 
> such comparisons for them (given that such types, not being arithmetic, do 
> *not* meet the constraints for == and !=), or make exceptions in those 
> places.

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:

…
[2] 	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.
…
[4]	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.
…

> 
> * The rules for default static initialization (6.7.9#10) cover pointers, 
> arithmetic types, aggregates and unions.  So with such a type not being 
> arithmetic, you need to define static initialization, presumably to 
> positive zero.

Right. Work needed there.

> 
> Then there are some other issues where the definition of both data 
> interchange types (whether or not interchange floating types) and extended 
> floating types is incomplete:
> 
> * Where are the syntax additions for the new types?  Should _FloatN, 
> _FloatNx, _DecimalN, _DecimalNx, for values of N supported by the 
> implementation, be keywords added to the list in 6.4.1#1?  They certainly 
> need to be matched by the type-specifier syntax (6.7.2#1).  And 
> appropriate combinations of specifiers (allowing _Complex or _Imaginary) 
> need to be added to the list of valid combinations in 6.7.2#2.

To be done.

> 
> * I'm not sure of the logic of supporting _Complex only with interchange 
> floating types; should implementations be permitted also to support it 
> with (binary) data interchange types that aren't interchange floating 
> types, and with (binary) extended floating types?  Likewise _Imaginary.

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.

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.
 
> 
> * There are references to such things as _Float32 being equivalent to 
> float.  What does "equivalent" mean here?  The types could be the same 
> type (like "long" and "long int").  They could be compatible types (like 
> "int" and an enum for which the implementation-defined compatible integer 
> type is int), but not the same.  They could be distinct (like "char" and 
> "unsigned char", even if char is unsigned) but have the same 
> representation and alignment.  Or one might imagine float having one 
> endianness and _Float32 the other (both being binary32); is that intended 
> to be ruled out?

> 
> If various possibilities for whether types are the same / compatible / 
> distinct but with the same values and (apart maybe from bit ordering) 
> representation are intended to be allowed, I think the TS should make 
> clear exactly what possibilities are permitted, rather than just using a 
> vague "equivalent".

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.

> 
> * The default argument promotions promote float to double when passed in 
> variable arguments (6.5.2.2#6).  Is such promotion permitted or required 
> for _Float32 (clearly it is if _Float32 is actually the same type as 
> float)?  What about for _Float16?  An application wishing to retrieve such 
> a value with va_arg needs to know the promoted type, since va_arg must be 
> called with the promoted type name (C11 7.16.1.1#2).

Yes, it needs to be specified.

> 
> * Are all the new types basic / fundamental types, so that malloc must 
> return memory suitably aligned for them (see my reflector message 12832 on 
> 9 Jan for more on the issues there)?  C11 6.2.5#14 says "The type char, 
> the signed and unsigned integer types, and the floating types are 
> collectively called the basic types.", leaving open the question of 
> whether data interchange types are also basic types.

Issue: how to assure that malloc can handle data-interchange types.

> 
> 
> Characteristics (pages 5-7):
> 
> * Must the value of DECIMAL_DIG be correct for all the new _FloatN and 
> _FloatNx types (floating integer types and extended floating types, not 
> ones that are only data interchange types), or just for float, double and 
> long double?

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.

> 
> 
> Conversions (pages 7-8):
> 
> * You say "Otherwise, if both operands are floating types and the sets of 
> values of their corresponding real types are equivalent, no further 
> conversion is needed.".  That is, the resulting type is left unspecified 
> if for example the operands are float and _Float32 but those are distinct 
> types.  I'd think it would be better to follow the practice for integer 
> types, where if two types have the same values the result is determined by 
> integer conversion rank, and require an implementation-defined total order 
> on real floating types with the same set of values (or completely define 
> such an order in this document rather than leaving it 
> implementation-defined).

Good issue.

> 
> 
> Mathematics <math.h> (pages 9-18):
> 
> * If an implementation doesn't support _Float128, say, are the function 
> and macro names associated with it still reserved for the implementation?  
> I'd say that they should be (and much the same applies to <float.h> macros 
> when <float.h> is included) - that might facilitate, for example, 
> implementations with full support for _Float32 and _Float64 but only 
> partial _Float128 support.  So it should be made clear what is reserved.  
> (I'd guess acosf256 is reserved but not acosf257, because of the rules on 
> which N have a _FloatN format defined.)

Yes, they should be reserved. Not acosf257.

> 
> * The statement on page 10 about SNANFN and SNANDN macros appears to be 
> the first use of the term "interface type".  This should probably be "data 
> interchange type".  

Right.

> But then for FP_FAST_FMAMFN and FP_FAST_FMADN you 
> introduce "interface floating type" - I guess this should be "interchange 
> floating type".

Right.

> 
> 
> Numeric conversion functions <stdlib.h> (pages 18-19):
> 
> * There are two references to __STDC_WANT_IEC_00000_EXT3__ that should use 
> the 18661 number.

Yes.

> 
> * Should there be wide-string analogues of these conversion functions 
> (analogues of wcstod / swprintf_s for the new types)?

Issue. I believe these were discussed but haven't found the rationale for omitting them.

> 
> 
> Other:
> 
> * You define some new complex types, but no associated <complex.h> 
> functions.  Should names for such functions such as cacosfN at least be 
> reserved to the implementation?  (And likewise for the future library 
> directions <complex.h> functions listed in 7.31.1#1.)

Yes, these are needed.

> 
> * Should <tgmath.h> be required to handle the new interchange floating 
> types and extended floating types?  (At least for real arguments, if you 
> don't define corresponding complex functions for the new types.)  
> Certainly part 2 extends it to cover decimal types.

Yes, not done yet.

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