This is subject to active issue 426 which says:
An example in 3.5 [basic.link] paragraph 6 creates two file-scope
variables with the same name, one with internal linkage and one with
external.
static void f();
static int i = 0; //1
void g() {
extern void f(); // internal linkage
int i; //2: i has no linkage
{
extern void f(); // internal linkage
extern int i; //3: external linkage
}
}
Is this really what we want? C99 has 6.2.2.7/7, which gives undefined
behavior for having an identifier appear with internal and external
linkage in the same translation unit. C++ doesn't seem to have an
equivalent.
The original proposal was to make it undefined behavior:
We agree that this is an error. We propose to leave the example but
change the comment to indicate that line //3 has undefined behavior,
and elsewhere add a normative rule giving such a case undefined
behavior.
but the last two comments say:
According to 3.5 [basic.link] paragraph 9, the two variables with
linkage in the proposed example are not “the same entity” because they
do not have the same linkage. Some other formulation will be needed to
describe the relationship between those two variables.
and:
The CWG decided that it would be better to make a program with this
kind of linkage mismatch ill-formed instead of having undefined
behavior.
The latest comments did not propose a new wording and it has not been updated since 2006, so at best we can say the current thinking is that this is ill-formed.
For reference the draft C99 standard 6.2.2.7/7
says:
If, within a translation unit, the same identifier appears with both internal and external
linkage, the behavior is undefined.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…