[Cfp-interest] Fwd: (SC22WG14.12843) CFP teleconference, documents
Jim Thomas
jaswthomas at sbcglobal.net
Fri Mar 8 11:41:47 PST 2013
Looks like the Cc to CFP didn't work, so I'm forwarding this separately.
-Jim
Begin forwarded message:
> From: Jim Thomas <jaswthomas at sbcglobal.net>
> Subject: Re: [Cfp-interest] (SC22WG14.12843) CFP teleconference, documents
> Date: March 7, 2013 11:53:57 AM PST
> To: "Joseph S. Myers" <jsm at polyomino.org.uk>
> Cc: CFP <cfp-interest at ucbtest.org>, SC22 WG14 <sc22wg14 at open-std.org>
>
> 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
>
>
> _______________________________________________
> Cfp-interest mailing list
> Cfp-interest at oakapple.net
> http://mailman.oakapple.net/mailman/listinfo/cfp-interest
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20130308/55c843f8/attachment-0001.html
More information about the Cfp-interest
mailing list