Title
Expressions with invalid results and ill-formedness
Status
cd1
Section
Clause [7] [expr]
Submitter
Gennaro Prota

Created on 2004-01-19.00:00:00 last changed 161 months ago

Messages

Date: 2005-10-15.00:00:00

[Voted into WP at October 2005 meeting.]

Date: 2004-10-15.00:00:00

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 expression is a constant expression appears where an integral constant expression is required (7.7 [expr.const]), in which case the program is ill-formed.
Date: 2004-09-15.00:00:00

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.

Date: 2004-03-15.00:00:00

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.

Date: 2020-12-15.00:00:00

Clause 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:00adminsetstatus: wp -> cd1
2006-04-22 00:00:00adminsetstatus: dr -> wp
2005-10-22 00:00:00adminsetmessages: + msg1273
2005-10-22 00:00:00adminsetstatus: ready -> dr
2005-05-01 00:00:00adminsetstatus: review -> ready
2004-11-07 00:00:00adminsetmessages: + msg1052
2004-11-07 00:00:00adminsetstatus: open -> review
2004-09-10 00:00:00adminsetmessages: + msg1040
2004-09-10 00:00:00adminsetstatus: nad -> open
2004-04-09 00:00:00adminsetmessages: + msg1033
2004-04-09 00:00:00adminsetstatus: open -> nad
2004-01-19 00:00:00admincreate