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
trueat 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
truein the evaluation of a core constant expression, the evaluation possibly fails. — end note]
Modify [dcl.attr.noreturn] as indicated:
- If a function
fis called wherefwas previously declared with thenoreturnattribute andfeventually 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
noreturnfunction returns in the evaluation of a core constant expression, the evaluation possibly fails. — end note]
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4