[cfp-interest 3413] Re: [SC22WG14.29686] WG14 2025/02 meeting action item: CFP to look at N3447's change 3.2, addition 50'

[Jim Thomas]

To address the action item from WG 14 how about we propose changing the second sentence in 6.6.1 #5 from:

… If a floating expression is evaluated in the translation environment, the arithmetic range and precision shall be at least as great as if the expression were being evaluated in the execution environment.

to:

… A floating expression evaluated in the translation environment is evaluated with arithmetic range and precision at least as great as if the expression were being evaluated in the execution environment.

with no addition to Annex J.

This avoids the “shall”, and hence the UB. It also clarifies that “arithmetic range and precision” pertains to the evaluation.

- Jim Thomas

> On Mar 12, 2025, at 1:01 PM, RAJAN BHAKTA <rbhakta at us.ibm.com> wrote:
> 
> Yes, that effort is underway with the UB study group and separately with Jens.
>  
> Regards,
> 
> Rajan Bhakta
> z/OS XL C/C++ Compiler Technical Architect
> ISO C Standards Representative (Canada, USA), INCITS/C Chair
> C/C++ Compiler Development
> rbhakta at us.ibm.com <mailto:rbhakta at us.ibm.com>
>  
> IBM
>  
>  
> From: Jim Thomas <jaswthomas at sbcglobal.net <mailto:jaswthomas at sbcglobal.net>>
> Date: Wednesday, March 12, 2025 at 2:49 PM
> To: RAJAN BHAKTA <rbhakta at us.ibm.com <mailto:rbhakta at us.ibm.com>>
> Cc: cfp-interest at oakapple.net <mailto:cfp-interest at oakapple.net> <cfp-interest at oakapple.net <mailto:cfp-interest at oakapple.net>>
> Subject: [EXTERNAL] Re: [cfp-interest 3410] [SC22WG14.29686] WG14 2025/02 meeting action item: CFP to look at N3447's change 3.2, addition 50'
> 
> The addition for (informative) Annex J is intended to be an implication of what is already in 6. 6. 1 #5. It, per se, shouldn't have any effect on what users can safely do. I think Joseph’s idea to change the “shall be” to “is” in 6. 6. 1 #5 (and
> The addition for (informative) Annex J is intended to be an implication of what is already in 6.6.1 #5. It, per se, shouldn't have any effect on what users can safely do.
>  
> I think Joseph’s idea to change the “shall be” to “is” in 6.6.1 #5 (and not add anything to Annex J) is reasonable. This suggests a broader effort to eliminate all uses of “shall” and “shall not” that apply to implementations instead of users. Rajan, did you say that effort was in progress?
>  
> - Jim Thomas
>  
> 
> 
> On Mar 12, 2025, at 9:49 AM, RAJAN BHAKTA <rbhakta at us.ibm.com> wrote:
>  
> In case people are not on the WG14 reflector.
>  
> Regards,
> 
> Rajan Bhakta
>  
>  
> From: owner-sc22wg14 at open-std.org <owner-sc22wg14 at open-std.org> on behalf of Joseph Myers <josmyers at redhat.com>
> Date: Wednesday, March 12, 2025 at 11:40 AM
> To: RAJAN BHAKTA <rbhakta at us.ibm.com>
> Cc: ISO C <sc22wg14 at open-std.org>
> Subject: [EXTERNAL] [SC22WG14.29686] WG14 2025/02 meeting action item: CFP to look at N3447's change 3.2, addition 50'
> 
> On Wed, 12 Mar 2025, RAJAN BHAKTA wrote:
> 
> > We suggest using the following wording instead:
> > 
> > (50’) A floating expression is evaluated in the translation environment 
> > with less arithmetic range or precision than if the expression were 
> > being evaluated in the execution environment.
> 
> The effect of that would seem to be that no program can safely use 
> floating-point expressions in constant expressions at all, in case the 
> implementation chooses to evaluate with less range or precision and so 
> give them undefined behavior.
> 
> I think we need a demons or ghosts paper to replace this "shall be" (in 
> 6.6.1) by "is" (or some similar change), since if there is UB here, there 
> should not be; the implementation should not be permitted to use less 
> range or precision in the translation environment.
> 
> -- 
> Joseph S. Myers
> josmyers at redhat.com
> _______________________________________________
> cfp-interest mailing list
> cfp-interest at oakapple.net <mailto: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/20250313/a1ad0923/attachment.htm>