Re: suspicious error 'static declaration follows non-static declaration'

[Tadeus Prastowo <tadeus.prastowo@xxxxxxxx>]

On Sun, Feb 18, 2018 at 2:09 PM, Andrew Makhorin <mao@xxxxxxx> wrote:
>
>> I think it is about fixing a conceptual bug given the following example:
>>
>> extern int i;  // external linkage
>> int f() {
>>   static int i;  // internal linkage
>>   {
>>     extern int i;  // external linkage before the change, internal
>> linkage after the change
>>   }
>> }
>>
>> I think the conceptual bug is because people expect the innermost i to
>> follow the i whose enclosing scope is most immediate.
>>
>
> Sorry for off-topic, but I see nothing wrong in your example. The
> innermost i being redeclared is not related to the static i, so both
> innermost and outermost i's represent the same object having external
> linkage.

You are right.  Sorry, I forgot that `static' gives an internal
linkage when at file scope as specified by section 6.2.2 par 3 of the
9899:1999 draft.

Then, the conceptual bug is given in the following example:

static int i; /* internal linkage */
void f() {
  int i;  /* no linkage */
  {
    extern int i;  /* internal linkage before TC, external linkage
after TC (also in 6.2.2 par 4 of 9899:1999 draft) */
  }
}

Before TC, the code compiles, but after TC and also in 9899:1999
draft, the code does not compile due to raising an undefined behavior.

So, yes, I think your argument that the change in the TC is to benefit
the compilation process makes sense.  The compiler does not have to
keep track of the outermost i upon seeing the i that has no linkage
because based on other paragraphs in 6.2.2, especially footnote 22,
the compiler only needs to keep track the linkage of the outermost
object/function if all intervening scopes also propagate the linkage;
once a declaration of the identifier having no linkage is seen, the
compiler can stop tracking for the remainder of the nested scopes.
Another reason from the user perspective may be that the keyword
`extern' really has to mean something that can exist outside of a
translation unit instead of just a global variable, which may be
confined to be within a single translation unit.

Anyway, as you said, this is off-topic.  So, I will stop here.

> Andrew Makhorin

--
Best regards,
Tadeus