Created on 2004-01-19.00:00:00 last changed 196 months ago
[Voted into WP at October 2005 meeting.]
Proposed resolution (October, 2004):
Change paragraph 5 of Clause 7 [expr] as indicated:
If during the evaluation of an expression, the result is not mathematically defined or not in the range of representable values for its type, the behavior is undefined, unless such an expressionis a constant expressionappears where an integral constant expression is required (7.7 [expr.const]), in which case the program is ill-formed.
Note (September, 2004):
Gennaro Prota feels that the CWG missed the point of his original comment: unless a constant expression appears in a context that requires a constant expression, an implementation is permitted to defer its evaluation to runtime. An evaluation that fails at runtime cannot affect the well-formedness of the program; only expressions that are evaluated at compile time can make a program ill-formed.
The status has been reset to “open” to allow further discussion.
Rationale (March, 2004):
We feel the standard is clear enough. The quoted sentence does begin "If during the evaluation of an expression, ..." so the rest of the sentence does not apply to an expression that is not evaluated.
Clause 7 [expr] par. 5 of the standard says:
If during the evaluation of an expression, the result is not mathematically defined or not in the range of representable values for its type, the behavior is undefined, unless such an expression is a constant expression (5.19), in which case the program is ill-formed.
Well, we do know that except in some contexts (e.g. controlling expression of a #if, array bounds), a compiler is not required to evaluate constant-expressions in compile time, right?
Now, let us consider, the following simple snippet:
if (a && 1/0) ...with a, to fix our attention, being *not* a constant expression. The quote above seems to say that since 1/0 is a constant (sub-)expression, the program is ill-formed. So, is it the intent that such ill-formedness is diagnosable at run-time? Or is it the intent that the above gives undefined behavior (if 1/0 is evaluated) and is not ill-formed?
I think the intent is actually the latter, so I propose the following rewording of the quoted section:
If an expression is evaluated but its result is not mathematically defined or not in the range of representable values for its type the behavior is undefined, unless such an expression is a constant expression (5.19) that shall be evaluated during program translation, in which case the program is ill-formed.
History | |||
---|---|---|---|
Date | User | Action | Args |
2008-10-05 00:00:00 | admin | set | status: wp -> cd1 |
2006-04-22 00:00:00 | admin | set | status: dr -> wp |
2005-10-22 00:00:00 | admin | set | messages: + msg1273 |
2005-10-22 00:00:00 | admin | set | status: ready -> dr |
2005-05-01 00:00:00 | admin | set | status: review -> ready |
2004-11-07 00:00:00 | admin | set | messages: + msg1052 |
2004-11-07 00:00:00 | admin | set | status: open -> review |
2004-09-10 00:00:00 | admin | set | messages: + msg1040 |
2004-09-10 00:00:00 | admin | set | status: nad -> open |
2004-04-09 00:00:00 | admin | set | messages: + msg1033 |
2004-04-09 00:00:00 | admin | set | status: open -> nad |
2004-01-19 00:00:00 | admin | create |