This is the mail archive of the
mailing list for the GCC project.
Re: New gcc 4.0.0 warnings seem spurious
Vincent Lefevre <email@example.com> writes:
| On 2005-04-27 03:37:15 -0700, Zack Weinberg wrote:
| > Vincent Lefevre <firstname.lastname@example.org> writes:
| > > However it is correct to store any integer to an unsigned variable,
| > > even if the original value cannot be represented.
| > If that operation occurs at runtime it has a well-defined result.
| And gcc 4 doesn't output a diagnostic in this case?
Why shall it?
| > If that operation occurs at compile time, as part of an initializer
| > expression, the overflow must be diagnosed (C99 6.6p4 - constraint
| > violation).
| Before the conversion, the value is representable in the type of
| the expression, and after the conversion (which is well-defined),
| it is still representable in the (new) type of the expression.
| 6.7.8#11 mentions the possible conversion. So, I disagree here.
| > > The fact that they are not considered as constant expressions,
| > > is it due to the fact that the environment is allowed to modify
| > > them?
| > No (and in fact the environment is not allowed to do that). It is
| > because the set of things that are allowed in constant expressions are
| > explicitly listed in C99 6.6, and read-only variables aren't one of
| > the things on the list.
| The only two constraints in 6.6 are:
In my version of the C standard, 6.6 contains *at least* these two
[#5] An expression that evaluates to a constant is required
in several contexts. If a floating expression is evaluated
in the translation environment, the arithmetic precision and
range shall be at least as great as if the expression were
being evaluated in the execution environment.
[#6] An integer constant expression96) shall have integer
type and shall only have operands that are integer
constants, enumeration constants, character constants,
sizeof expressions whose results are integer constants, and
floating constants that are the immediate operands of casts.
Cast operators in an integer constant expression shall only
convert arithmetic types to integer types, except as part of
an operand to the sizeof operator.
Clearly, 6.6/6 rules out AAA from being an integer constant.
| [#3] Constant expressions shall not contain assignment,
| increment, decrement, function-call, or comma operators,
| except when they are contained within a subexpression that
| is not evaluated.86)
| [#4] Each constant expression shall evaluate to a constant
| that is in the range of representable values for its type.
| #3 doesn't include variables. #4 is OK if one considers that the
| value cannot be modified.
| #6 adds other requirements, but this is out of the scope of the
| given diagnostic (which complained about an expression not being a
| constant -- not because it wasn't an integer constant expression).
| Couldn't the expression fall into #10 with some implementations?