[defns.undefined] Fix the note on undefined behavior in constant evaluation by frederick-vs-ja · Pull Request #7206 · cplusplus/draft (original) (raw)
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters
[ Show hidden characters]({{ revealButtonHref }})
Currently, the assmue and noreturn attributes are allowed to bring undefined behavior into constant evaluation. There might be more such standard attributes in the future.
(Attempted to fix) #7042.
No, that's not the intent. We want that rule "never undefined behavior in constant evaluation" to hold. We do have special rules for the mentioned attributes; see [expr.const] p6.3 and p6.4.
Currently, the assmue and noreturn attributes are allowed to bring undefined behavior into constant evaluation. There might be more such standard attributes in the future.
We do have special rules for the mentioned attributes; see [expr.const] p6.3 and p6.4.
The original issue was exactly concerned about these special rules. Is there better way to mention these exceptions in the note?
Your claim was "Currently, the assmue and noreturn attributes are allowed to bring undefined behavior into constant evaluation."
I pointed to the text where that claim is refuted: We continue not to have UB in constant evaluation; we just sometimes make that evaluation not a constant evaluation anymore. In particular, a returning [[noreturn]] function is not UB in constant evaluation; it just keeps going (unless detected).
In particular, a returning [[noreturn]] function is not UB in constant evaluation; it just keeps going (unless detected).
So is the intent that when returning from a [[noreturn]] function happens to be allowed in the evaluation of some constant expression, UB is not considered happening?
That's my understanding: If a [[noreturn]] function returns in constant evaluation, it's either no longer constant evaluation (if your compiler detects that), or it's as-if [[noreturn]] were absent. This is consistent with the idea that attributes can be ignored.
That's my understanding: If a [[noreturn]] function returns in constant evaluation, it's either no longer constant evaluation (if your compiler detects that), or it's as-if [[noreturn]] were absent. This is consistent with the idea that attributes can be ignored.
Oh I see. Then perhaps we should clarify [[noreturn]] and [[assume]] never bring UB into constant evaluation instead.
But this isn't what [dcl.attr.assume] and [dcl.attr.noreturn] currently say. Related UB is not excluded from constant evaluation, which seemingly allows constant expression to have arbitrary result when the restrictions are violated. Should there be a CWG issue?
Closing as the clarification doesn't seem editorial.
2 participants
