What should the third x
refer to in:
#include <stdio.h>
static char x = '1';
int main(void)
{
char x = '2';
{
extern char x;
printf("%c\n", x);
}
}
This arose in this answer, and:
x
of extern char x
refers to the first x
, and “1” is printed.C 2018 6.2.2 4 says:
For an identifier declared with the storage-class specifier extern in a scope in which a prior declaration of that identifier is visible, if the prior declaration specifies internal or external linkage, the linkage of the identifier at the later declaration is the same as the linkage specified at the prior declaration. If no prior declaration is visible, or if the prior declaration specifies no linkage, then the identifier has external linkage.
Since there are two prior declarations of x
, the condition of each of the following “if” clauses is true, the first for the first prior declaration, and the second for the second prior declaration:
Clang’s behavior here is consistent with using the first clause, so that the third x
has internal linkage and refers to the same object as the first x
. GCC’s behavior here is consistent with using the second clause, so that the third x
has external linkage and conflicts with the first x
, which has internal linkage.
Does the C standard give us a way to resolve which of these should be the case?
You use extern to tell the compiler that the variable is defined elsewhere. Without extern in your program compiler would define another variable a (in addition to this in the global scope) in your main() function that would be printed uninitialized.
To actually use an external global variable that has been defined in another file, you also must place a forward declaration for the global variable in any other files wishing to use the variable. For variables, creating a forward declaration is also done via the extern keyword (with no initialization value).
The term external linkage means that a symbol in one translation unit can be accessed from other translation units, whereas exporting refers to a symbol that is visible from a library file such as a DLL. Only external linkage symbols can be exported.
The third declaration, extern char x
, should declare x
with external linkage, based on C 2018 6.2.2 4, which says:
For an identifier declared with the storage-class specifier extern in a scope in which a prior declaration of that identifier is visible, if the prior declaration specifies internal or external linkage, the linkage of the identifier at the later declaration is the same as the linkage specified at the prior declaration. If no prior declaration is visible, or if the prior declaration specifies no linkage, then the identifier has external linkage.
At the declaration extern char x
, the first declaration of x
is not visible, as it has been hidden by the second declaration. Therefore, it does not qualify for “a prior declaration of that identifier is visible.” The second declaration of x
is visible, so it is a “prior declaration” for the purposes of the above paragraph.
Then the last sentence should control: The prior declaration specifies no linkage (6.2.2 6, a block-scope identifier without extern
has no linkage), so the third x has external linkage.
Then 6.2.2 7 is violated because the first x
has internal linkage and the third x
has external linkage:
If, within a translation unit, the same identifier appears with both internal and external linkage, the behavior is undefined.
Since no syntax rule or constraint is violated, the C implementation is not required by the standard to report a diagnostic. Since the behavior is undefined, it may do anything, including accept this code and make the third x
refer to the same object as the first x
. Therefore, neither Clang nor GCC’s behaviors violate the standard in this regard. However, since 6.2.2 7 is violated, a diagnostic may be preferred, and its absence could be consider a defect of Clang.
(Credit to Paul Ogilvie and T.C. for informing my thinking on this with their comments.)
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With