Skip to content

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

Description

@frederick-vs-ja

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]

Activity

  1. jensmaurer commented on Aug 13, 2024

    @jensmaurer
    Member

    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.

  2. changed the title [-][dcl.attr.assume, dcl.attr.noreturn] Clarify that violation of the restrictions of standard attributes does not cause undefined behavior in constant evaluation[/-] [+]CWG2924 [dcl.attr.assume, dcl.attr.noreturn] Clarify that violation of the restrictions of standard attributes does not cause undefined behavior in constant evaluation[/+] on Aug 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions