gcc: why is "abcdef"[3] not a constant (error: initializer element is not constant)

Andrew Haley aph@redhat.com
Mon May 11 17:23:00 GMT 2015


On 05/11/2015 04:44 PM, Martin Sebor wrote:
>>> I just did not understand the idea behind this restriction. Perhaps
>>> there is a good reason (beside the standard) for this.
>>
>> I don't think there is.  There has to be some limit on how far to do
>> constant propagation.  This limit is necessarily arbitrary: there is
>> no obvious point at which to say "this far, and no further."
> 
> The C constraint that initializers of objects with static
> storage duration be constant expressions is in place to
> keep the implementation of program startup as simple as
> possible and avoid dependencies between object values at
> this stage.
> 
> There are cases when this constraint is overly restrictive
> and unnecessary. The C standard recognizes that

Does it really?  I'm not aware of any such language.  There is of
course implicitly permission for an implementation to do anything
whatsoever as long as it doesn't break any standard program or fail to
issue a required dignostic, but that is a very long way from
"recognzing that a constraint is overly restrictive and unnecessary."
At least, I can't find it in the standard or the rationale.  Perhaps
you're aware of some language I've missed.

> and permits implementations to accept other forms of constant
> expressions (such as "abcdef"[3]) beyond those explicitly listed.
> 
> The same constraint doesn't exist in C++ because the language
> has dynamic initialization of such objects as a general feature
> (with all its benefits and liabilities).

Regardless of where you draw the line, there has to be a line.  A
sensible default for GCC (IMO) is the language specification.

C++11, in particular, has a completely different definition of what
constitutes a constant expression.  Even some kinds of user-defined
function calls are allowed, and the OP's exaple is legal.  This is
doubtless a good thing for users of C++, but isn't relevant here.

Andrew.



More information about the Gcc-help mailing list