search

cplusplus / CWG

Core Working Group
23 stars 7 forks source link

CWG2924 [dcl.attr.assume, dcl.attr.noreturn] Clarify that violation of the restrictions of standard attributes does not cause undefined behavior in constant evaluation #595

Open frederick-vs-ja opened 1 month ago

frederick-vs-ja commented 1 month ago

Full name of submitter (unless configured in github; will be published with the issue): Jiang An

Reference (section label): [expr.const], [dcl.attr.assume], [dcl.attr.noreturn]

Link to reflector thread (if any):

Issue description:

Per the discussion in cplusplus/draft#7206, the intent seems to be that in the evaluation of a constant expression, violation of the restrictions of standard attributes either make the expression not a constant expression or has no effect, and no UB should be introduced in constant evaluation.

Suggested resolution:

Modify [expr.const] as indicated:

[...] (5.8) - an operation that would have undefined or erroneous behavior as specified in [intro] through [cpp]~, excluding [dcl.attr.assume] and [dcl.attr.noreturn]~; [...]

Modify [dcl.attr.assume] as indicated:

[...] If the converted expression would evaluate to true at the point where the assumption appears, or in the evaluation of a core constant expression ([expr.const]), the assumption has no effect. Otherwise, the behavior is undefined. [...]

Add a new note after [dcl.attr.assume] Note 1:

[Note ?: If the converted expression would not evaluate to true in the evaluation of a core constant expression, the evaluation possibly fails. — end note]

Modify [dcl.attr.noreturn] as indicated:

  1. If a function f is called where f was previously declared with the noreturn attribute and f eventually returns and the function call is not evaluated in the evaluation of a core constant expression ([expr.const]), the behavior is undefined.

Add a new note after [dcl.attr.noreturn] Note 1:

[Note ?: If a noreturn function returns in the evaluation of a core constant expression, the evaluation possibly fails. — end note]

jensmaurer commented 1 month ago

I've made CWG2924 for this.

I've thought a little more about this, and it seems just fixing the note in [defns.undefined] is a plausible approach, given that we already have "library" undefined behavior in constant expressions anyway.

However, "as if the attribute is ignored" seems also like a plausible approach.