On 2005-04-27 03:37:15 -0700, Zack Weinberg wrote:
> Vincent Lefevre <[EMAIL PROTECTED]> 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?
> 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:
[#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?
--
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA
