[Cfp-interest 3225] Re: [SC22WG14.26243] constexpr initialization seemingly can contain UB?

[Jim Thomas]

> On Aug 14, 2024, at 8:13 AM, Fred J. Tydeman <tydeman at tybor.com> wrote:
> 
> ..................Begin Forwarded Message..................
> 
> From: Aaron Ballman <aaron at aaronballman.com>
> To: Joseph Myers <josmyers at redhat.com>
> Cc: wg14 <sc22wg14 at open-std.org>
> Date: Thu, 1 Aug 2024 13:33:18 -0400
> Subject: [SC22WG14.26243] constexpr initialization seemingly can contain UB?
> 
> On Thu, Aug 1, 2024 at 12:59PM Joseph Myers <josmyers at redhat.com> wrote:
>> 
>> On Thu, 1 Aug 2024, Aaron Ballman wrote:
>> 
>>> Consider the following example:
>>> 
>>> constexpr float f = 1.0f / 0.0f
>>> 
>>> According to my reading of the C23 standard, this is conforming and
>>> should result in `f` holding infinity, presuming that the target
>>> supports infinities in their floating-point representation (see
>>> 5.2.5.3.3 for what is "in the range of representable values")
>>> 
>>> However, 6.5.6p6 makes this undefined behavior explicitly:
>>> The result of the / operator is the quotient from the division of the
>>> first operand by the second; the result of the % operator is the
>>> remainder. In both operations, if the value of the second operand is
>>> zero, the behavior is undefined.
>> 
>> It was previously stated in response to DR#442 that "WG14 treats normative
>> annexes such as Annex F as if they were linear extensions of the standard
>> itself. When Annex F is requested via definition of __STDC_IEC_559__ then
>> 6.5#5 is superseded and floating point exceptions become well defined.".
>> I think that applies to the specification of the division operator just as
>> to the general statement about exceptional conditions - the rules for
>> translation-time evaluation thus apply, as long as Annex F is implemented,
>> to give the result of evaluating that expression in the default rounding
>> mode with default exception handling and exceptions discarded.  See the
>> example in F.8.5.
> 
> Agreed, but Annex F doesn't save us here -- there are targets for
> which my implementation cannot conform to Annex F for <reasons>, and
> we don't claim conformance on any target currently by defining the
> __STDC_IEC_559__ macro.

3.5.3 (undefined behavior) #2 says:

Note 1 to entry: Possible undefined behavior ranges from ignoring the situation completely with unpredictable
results, to behaving during translation or program execution in a documented manner characteristic of the
environment (with or without the issuance of a diagnostic message), ...

This would seem to mean an implementation that does not declare support for Annex F but that does document its support for infinity could set f to +infinity without issuing a diagnostic message. 

Does this help?

- Jim Thomas

> 
> ~Aaron
> 
>> 
>> --
>> Joseph S. Myers
>> josmyers at redhat.com
>> 
> 
> ...................End Forwarded Message..................
> 
> 
> ---
> Fred J. Tydeman        Tydeman Consulting
> tydeman at tybor.com      Testing, numerics, programming
> +1 (702) 608-6093      Vice-chair of INCITS/C (ANSI "C")
> Sample C17+FPCE tests: http://www.tybor.com
> Savers sleep well, investors eat well, spenders work forever.
> 
> _______________________________________________
> Cfp-interest mailing list
> 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/20240818/fdfb2854/attachment.htm>