5

The following (admittedly contrived) C program fails to compile:

int main() {
const int array[] = {1,2,3};
static int x = array[1];
}

When compiling the above C source file with gcc (or Microsoft's CL.EXE), I get the following error:

error: initializer element is not constant
static int x = array[1];
               ^

Such simple and intuitive syntax is certainly useful, so this seems like it should be legal, but clearly it is not. Surely I am not the only person frustrated with this apparently silly limitation. I don't understand why this is disallowed-- what problem is the C language trying to avoid by making this useful syntax illegal?

It seems like it may have something to do with the way a compiler generates the assembly code for the initialization, because if you remove the "static" keyword (such that the variable "x" is on the stack), then it compiles fine.

However, another strange thing is that it compiles fine in C++ (even with the static keyword), but not in C. So, the C++ compiler seems capable of generating the necessary assembly code to perform such an initialization.

Edit: Credit to Davislor-- in an attempt to appease the SO powers-that-be, I would seek following types of factual information to answer the question:

  1. Is there any legacy code that supporting these semantics would break?

  2. Have these semantics ever been formally proposed to the standards committee?

  3. Has anyone ever given a reason for rejecting the allowance of these semantics?

deltamind106
  • 638
  • 7
  • 19

2 Answers2

6

Objects with static storage duration (read: variables declared at file scope or with the static keyword) must be initialized by compile time constants.

Section 6.7.9 of the C standard regarding Initialization states:

4 All the expressions in an initializer for an object that has static or thread storage duration shall be constant expressions or string literals.

Section 6.6 regarding Constant Expressions states:

7 More latitude is permitted for constant expressions in initializers. Such a constant expression shall be, or evaluate to, one of the following:

  • an arithmetic constant expression,
  • a null pointer constant,
  • an address constant, or
  • an address constant for a complete object type plus or minus an integer constant expression.

8 An arithmetic constant expression shall have arithmetic type and shall only have operands that are integer constants, floating constants, enumeration constants, character constants, sizeof expressions whose results are integer constants, and _Alignof expressions. Cast operators in an arithmetic constant expression shall only convert arithmetic types to arithmetic types, except as part of an operand to a sizeof or _Alignof operator.

9 An address constant is a null pointer, a pointer to an lvalue designating an object of static storage duration, or a pointer to a function designator; it shall be created explicitly using the unary & operator or an integer constant cast to pointer type, or implicitly by the use of an expression of array or function type. The array-subscript [] and member-access . and -> operators, the address & and indirection * unary operators, and pointer casts may be used in the creation of an address constant, but the value of an object shall not be accessed by use of these operators.

By the above definition, a const variable does not qualify as a constant expression, so it can't be used to initialize a static object. C++ on the other had does treat const variables as true constants and thus allows them to initialize static objects.

dbush
  • 205,898
  • 23
  • 218
  • 273
  • I think this compiles in C++ because C++ doesn't require static initializers to be constant expressions, not because `array[1]` can be deduced at compile time. In a context which really required a constant expression, `array[1]` wouldn't be feasible. (https://godbolt.org/g/HhqySp). (Of course, C++ gives you the option to make `array` a `constexpr`.) – rici Jun 27 '18 at 16:02
  • @rici C++ has `constexpr` expressions that must be initialized to compile-time constants, which would seem to be fairly analogous. You can declare an array `constexpr` in C++ and use its elements as compile-time constants. – Davislor Jun 27 '18 at 16:04
  • @davislor: Yes, I said that at the end of my comment. But *in this particular case*, the array is neither static nor constexpr, so I don't see how indexing into it can produce a constant expression, even with C++'s generous definition of constant expressions. The last line of the answer says "C++ on the other had does treat const variables as true constants", which is what I was reacting to. – rici Jun 27 '18 at 16:49
  • Does *"on the other had"* mean *"on the other **hand**"*? – Pang Jul 27 '18 at 01:49
1

If the C standard allowed this, then compilers would have to know what is in arrays. That is, the compiler would have to have a compile-time model of the array contents. Without this, the compiler has a small amount of work to do for each array: It needs to know its name and type (including its size), and a few other details such as its linkage and storage duration. But, where the initialization of the array is specified in the code, the compiler can just write the relevant information to the object file it is growing and then forget about it.

If the compiler had to be able to fetch values out of the array at compile time, it would have to remember that data. As arrays can be very large, that imposes a burden on the C compiler that the committee likely did not desire, as C is intended to operate in a wide variety of environments, including those with constrained resources.

The C++ committee made a different decision, and C++ is much more burdensome to translate.

Eric Postpischil
  • 195,579
  • 13
  • 168
  • 312
  • 2
    That's not really much of a problem. See Pascal, Modula or even Oberon (the latter supports OOP, too). Those are similar complex languages (actually the compilers are much less complex than C compilers) which don't have a problem with this. And Pascal is of a similar age like K&R C, Modula older than C89. – too honest for this site Jun 27 '18 at 15:55
  • @Olaf: “Much of a problem” is a judgement call. I am not saying the C committee’s judgement was or was not good; my answer explains how requiring support for the feature imposes some cost. As to your assertion about compiler sizes, are you comparing them on the **smallest** platforms there are C compilers for? Comparing sizes on average platforms is not informative in this regard. What does a Pascal compiler do when the user initializes a compile-time constant with an arbitrary element of a large array? Does it have it in memory? Rely on external storage? – Eric Postpischil Jun 27 '18 at 16:22
  • 1
    My point is, this is not necessarily the reason. If it was, other features like atomics, threads, etc would have not been implemented either, because they add even more complexity to the compiler. The question is all about specualtion about the motivation of the commitee and/or Ritchie. Unless we have 1st place information here, it's all POB. – too honest for this site Jun 27 '18 at 16:56
  • @Olaf: Again, you are making judgements. You have judged that the benefit of atomics relative to their costs must be less than the benefit of initialization from arrays relative to its cost, therefore taking the former implies taking the latter. Additionally, the atomic and threads headers are optional. Can you suggest any other reason? – Eric Postpischil Jun 27 '18 at 17:03
  • 1
    Who is making judegements? I just listed some examples. Apparently C has been used fine for any kind of software successfully without them before. Similar to threads. All I said is you are pointlessly speculating (judgement? - who?) – too honest for this site Jun 27 '18 at 17:07
  • @Olaf: You did not just list examples, You wrote an if-then statement that requires ranking whether things should be added to the language. It is an assertion about the relative values of those things. – Eric Postpischil Jun 27 '18 at 17:20