Sujet : Re: Constants and undefined behavior
De : Keith.S.Thompson+u (at) *nospam* gmail.com (Keith Thompson)
Groupes : comp.lang.cDate : 07. Jun 2026, 00:36:14
Autres entêtes
Organisation : None to speak of
Message-ID : <1102ate$25nse$1@kst.eternal-september.org>
References : 1 2 3 4 5 6 7
User-Agent : Gnus/5.13 (Gnus v5.13)
Tim Rentsch <
tr.17687@z991.linuxsc.com> writes:
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
I claim that an expression that looks like a constant expression
*isn't* a constant-expression if it doesn't appear in a context
that requires a constant-expression.
>
Right. This question came up years ago in a Defect Report. The
response from the Committee was basically the same as what you
said: the 6.6 constraints for constant expressions apply only in
situations where the C standard expressly requires a constant
expression. (I don't have the DR in front of me; I'm summarizing
based on memory, but am confident the actual wording is consistent
with what I just said.)
C99 DR 261 looks similar to what you're talking about.
https://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_261.htmThe Committee Response section says:
In general, the interpretation of an expression for constantness
is context sensitive. For any expression which contains only
constants:
- If the syntax or context only permits a constant expression, the
constraints of 6.6#3 and 6.6#4 shall apply.
- Otherwise, if the expression meets the requirements of 6.6
(including any form accepted in accordance with 6.6#10), it is a
constant expression.
- Otherwise it is not a constant expression.
That's close to what I claimed, but the second bullet point differs.
My claim was that, given:
n = 2+2;
2+2 is not a constant expression because the grammar doesn't require
a constant expression in that context. The Committee's opinion
(at least at the time) was that it is a constant expression because
it meets the requirements of 6.6.
But I *think* it's a distinction without a difference. Calling 2+2
a constant expression has no effect on the semantics, and does not
require or forbid the implementation from, for example, generating
an ADD instruction. The distinction would matter for an expression
that has UB and/or does not yield a value of the type, but that
falls through to the third bullet.
I found another interesting tidbit, C90 DR 031, relevant to another
point I made elsethread:
https://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_031.html case (INT_MAX*4)/4: is a constraint violation.
When subclause 6.4 says on page 55, lines 11-12:
Each constant expression shall evaluate to a constant that is in
the range of representable values for its type.
the Committee's judgement of the intent is that the
``representable'' requirement applies to each subexpression of a
constant expression, as shown in the third example. A constant
expression is meant as defined by the syntax rules.
-- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.comvoid Void(void) { Void(); } /* The recursive call of the void */
Haut de la page
Les messages affichés proviennent d'usenet.
NewsPortal