[Cfp-interest] Fwd: interchange types, equivalence, basic types

[Jim Thomas]

Begin forwarded message:

> From: Jim Thomas <jaswthomas at sbcglobal.net>
> Subject: interchange types, equivalence, basic types 
> Date: March 12, 2013 11:16:23 AM PDT
> To: Joseph S. Myers <jsm at polyomino.org.uk>
> Cc: SC22 WG14 <sc22wg14 at open-std.org>
> 
> 
> On Mar 7, 2013, at 11:53 AM, Jim Thomas <jaswthomas at sbcglobal.net> wrote:
> 
> …
> 
>> On Mar 6, 2013, at 2:36 PM, Joseph S. Myers <jsm at polyomino.org.uk> wrote:
>> 
>>> 
> ...
>>> * 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.
>> 
>> 
> 
> Is there any reason to require a stricter sense of "equivalence" than in the following?
> 
> An implementation that defines __STDC_IEC_60559_BFP__ shall provide:
>  _Float32 and _Float64 as interchange floating types with the same representation and alignment requirements as float and double, respectively
>  _Float16 as a data-interchange type
> and may provide:
> 
> _Float16 as an interchange floating type
> 
> If the implementation’s long double type supports an IEC 60559 interchange format of width N, then the implementation shall provide the type _FloatN as an interchange floating type with the same representation and alignment requirements as long double.
> 
> 
> ...
>>> 
>>> * 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.
>> 
>> 
> 
> Any problem with including data-interchange types as basic types?
> 
> The type char, the signed and unsigned integer types, the floating types, and the data-interchange types are collectively called the basic types.
> 
> 
> -Jim Thomas

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20130312/457b6b3e/attachment.html