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

[RAJAN BHAKTA]

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>
Date: Wednesday, March 12, 2025 at 2:49 PM
To: RAJAN BHAKTA <rbhakta at us.ibm.com>
Cc: cfp-interest at oakapple.net <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<http://mailman.oakapple.net/mailman/listinfo/cfp-interest >

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20250312/3a02f162/attachment-0001.htm>