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

[Jim Thomas]

Begin forwarded message:

> From: "Joseph S. Myers" <jsm at polyomino.org.uk>
> Subject: Re: (SC22WG14.12843) CFP teleconference, documents
> Date: March 6, 2013 2:36:05 PM PST
> To: Jim Thomas <jaswthomas at sbcglobal.net>
> Cc: SC22 WG14 <sc22wg14 at open-std.org>
> 
> 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.  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.
> 
> * 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.
> 
> 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.
> 
> * 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.
> 
> * 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".
> 
> * 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).
> 
> * 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.
> 
> 
> 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?
> 
> 
> 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).
> 
> 
> 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.)
> 
> * 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".  But then for FP_FAST_FMAMFN and FP_FAST_FMADN you 
> introduce "interface floating type" - I guess this should be "interchange 
> floating type".
> 
> 
> Numeric conversion functions <stdlib.h> (pages 18-19):
> 
> * There are two references to __STDC_WANT_IEC_00000_EXT3__ that should use 
> the 18661 number.
> 
> * Should there be wide-string analogues of these conversion functions 
> (analogues of wcstod / swprintf_s for the new types)?
> 
> 
> 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.)
> 
> * 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.
> 
> -- 
> Joseph S. Myers
> joseph at codesourcery.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20130307/636056e1/attachment.html