[Cfp-interest] Fw: (SC22WG14.15205) Pointer Operations

[Rajan Bhakta]

Joseph's reply... Sorry for not forwarding sooner. I had thought I had 
done it already.

Regards,

Rajan Bhakta
z/OS XL C/C++ Compiler Technical Architect
ISO C Standards Representative for Canada, PL22.11 Chair (USA)
C Compiler Development
Contact: rbhakta at us.ibm.com, Rajan Bhakta/Houston/IBM
----- Forwarded by Rajan Bhakta/Houston/IBM on 06/21/2018 10:18 AM -----

From:   Joseph Myers <joseph at codesourcery.com>
To:     Rajan Bhakta <rbhakta at us.ibm.com>
Date:   05/22/2018 02:29 PM
Subject:        Re: (SC22WG14.15205) Pointer Operations



On Tue, 22 May 2018, Rajan Bhakta wrote:

> Hi Joseph,
> 
> I agree, and it's been part of the C FP proposals to get feedback and 
> experience before strongly pushing any of the parts into C2X. Do you 
have 
> specific feedback on any parts you want to see added and ones you don't 
or 
> haven't implemented?

Well, I've implemented most of part 1, other than constant rounding modes, 

and part 3 for _FloatN / _FloatNx types, other than the new functions that 

don't have float / double / long double analogues, and think the issues 
I've found there have generally been addressed through the DR process.

I've not done anything with part 2 (or the _Decimal* parts of part 3) and 
don't know to what extent new features from there have been implemented (I 

think a few new functions may have been implemented in libdfp, but not 
most of them).

I've not done anything with parts 4 and 5 and don't know to what extent 
features from there may have been implemented at all (beyond glibc already 

having had the exp10 functions for a long time).

For part 1, if features are integrated into C2X, I think it's appropriate 
to consider case-by-case whether some features should be unconditional 
features of C2X (required to be supported, defined or declared without 
requiring any feature test macros to be defined).  For example, the 
integer width macros, which are only very peripherally related to floating 

point and are easy to implement, would be a good candidate for such an 
unconditional feature, but more of the features, other than those for 
which the prototypes are only defined in Annex F, could be appropriate for 

such unconditional features (to the extent that they are similar features 
to functions required unconditionally since C99).

-- 
Joseph S. Myers
joseph at codesourcery.com



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