[Cfp-interest] (SC22WG14.14286) TS 18661-3 and usual arithmetic conversions for long double, double

[Jim Thomas]

> On Jun 21, 2016, at 2:39 PM, Joseph Myers <joseph at codesourcery.com> wrote:
> 
> On Tue, 21 Jun 2016, Jim Thomas wrote:
> 
>> Otherwise, if the corresponding real type of either operand is long 
>> double, the other operand is converted, without change of type domain, 
>> to a type whose corresponding real type is long double.
>> 
>> Otherwise, if the corresponding real type of either operand is double, 
>> the other operand is converted, without change of type domain, to a type 
>> whose corresponding real type is double.
> 
> I'd rather add a statement about either type being float here, before 
> going on to _FloatNx and _DecimalNx.  That makes it clear that the 
> standard types always take precedence over _FloatNx or _DecimalNx with the 
> same set of values.  (Consider an implementation of parts 2 and 3 but not 
> part 1, where float has the same set of values as one of the _FloatNx 
> types.  Is it valid to have some _FloatNx types even when part 1 is not 
> implemented?  

No. Paragraph 6.2.5#10c in Part 3 is meant to say an implementation that defines __STDC_IEC_60559_BFP__ and __STDC_IEC_60559_TYPES__ must provide certain of the _FloatN and _FloatNx types and may provide others. Paragraph 6.2.5#10d is a similar specification for __STDC_IEC_60559_DFP__ and decimal types.

> Even if not, mentioning float here seems cleaner than just 
> mentioning long double and double.)

It would be specifying a vacuous case. The types that might have the same set of values as float (_Float32, double, long double) have already been covered. If not mentioning float is confusing, would adding a parenthetical remark or note help?

Jim Thomas

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