External linkage of const in C

Question

I was playing with extern keyword in C when I encountered this strange behaviour. I have two files:

file1.c

#include<stdio.h>
int main()
{
    extern int a;
    a=10;
    printf("%d",a);
    return 0;
}

file2.c

const int a=100;

When I compile these files together, there is no error or warning and when I run them, output comes to be 10. I had expected that the compiler should report an error on line a=10;.

Moreover, if I change the contents of file2.c to

const int a;

that is, if I remove the initialization of global const variable a and then compile the files, there is still no error or warning but when I run them, Segmentation Fault occurs.

Why does this phenomenon happen? Is it classified under undefined behaviour? Is this compiler- or machine- dependent?

PS: I have seen many questions related to this one, but either they are for C++ or they discuss extern only.

It is a very nice answer but it does not answer my question. — skrtbhtngr, Oct 29 '16 at 18:38

score 1 · Answer 1 · edited May 23 '17 at 12:00

Compilation and linking are two distinct phases. During compilation, individual files are being compiled into object files. Compiler will find both file1.c and file2.c being internally consistent. During linking phase, the linker will just point all the occurrence of the variable a to the same memory location. This is the reason you do not see any compilation or linker error.

To avoid exactly the problem which you have mentioned, it is suggested to put the extern in a header file and then include that header file in different C file. This way compiler can catch any inconsistency between the header and the C file

The following stackoverflow also speaks about linker not able to do type checking for extern variables.

Is there any type checking in C or C++ linkers?

Similarly, the types of global variables (and static members of classes and so on) aren't checked by the linker, so if you declare extern int test; in one translation unit and define float test; in another, you'll get bad results.

score 0 · Answer 2 · answered Oct 29 '16 at 18:45

It is undefined behaviour but the compiler won't warn you. How could it? It has no idea how you declare a variable in another file.

Attempting to modify a variable declared const is undefined behaviour. It is possible (but not necessary) that the variable will be stored in read-only memory.

score 0 · Answer 3 · answered Oct 29 '16 at 18:51

0

This is a known behavior of C compilers. It is one of the differences between C and C++ where strong compile time type checking is enforced. The segmentation fault occurs when trying to assign a value to a const, because the linker puts the const values in a read-only elf segment and writing to this memory address is a runtime (segmentation) fault. but during compile time, the compiler does not check any "externs", and the C linker, does not test types. therefore it passes compilation/linkage.

answered Oct 29 '16 at 18:51

Yanir

21
2

Yanir, you have a sentence 'It is one of the differences between C and C++ where strong compile time type checking is enforced'. Do you meant to say that C++ compiler would have caught this issue? Since the files are different, they might be compiled separately into object files. – Jay Rajput Oct 29 '16 at 18:56
@JayRajput C++ compiler would not have caught this, but the linker would have. – user4581301 Oct 29 '16 at 19:14
1

@user4581301, there seems to be confusing information online. For example: this stackoverflow article suggest that the linker will not be doing type checking for extern variables. http://stackoverflow.com/questions/28090854/is-there-any-type-checking-in-c-or-c-linkers. Do you have some source which proves that linker does do type checking for extern variables? I would like to understand more about it. – Jay Rajput Oct 29 '16 at 19:20
@JayRajput I'll have to do some standard-reading to find the exact wording. The question you linked tries to answer for both C and C++, and they are very, very different beasts when it comes to type checking. See Yakk's comment and Josh Kelly's answer. – user4581301 Oct 29 '16 at 19:29
@JayRajput Looks like it works a bit differently than I thought it would. According to **Basic.Link**, a `const` type has internal linkage and cannot be seen outside the current file unless explicitly declared as `extern`.So `const int x = 0;` cannot be `extern`ed, but `extern const int x = 0;` can be `extern`ed. I can't find any information on whether or not the missing `const` is trapped by the linker. GCC 4.8 and 6.1 do not seem to trap, so for the moment I'm assuming It's not required. – user4581301 Oct 29 '16 at 20:04
And now that I know what keywords to look for, [Why does “extern const int n;” not work as expected?](http://stackoverflow.com/questions/14894698/why-does-extern-const-int-n-not-work-as-expected) Good educational day. Now back to work cleaning the house. – user4581301 Oct 29 '16 at 20:07

score 0 · Answer 4 · answered Oct 30 '16 at 08:56

Your program causes undefined behaviour with no diagnostic required (whether or not const int a has an initializer). The relevant text in C11 is 6.2.7/2:

All declarations that refer to the same object or function shall have compatible type; otherwise, the behavior is undefined.

Also 6.2.2/2:

In the set of translation units and libraries that constitutes an entire program, each declaration of a particular identifier with external linkage denotes the same object or function.

In C, const int a = 100; means that a has external linkage. So it denotes the same object as extern int a;. However those two declarations have incompatible type (int is not compatible with const int, see 6.7.2 for the definition of "compatible type").

External linkage of const in C

4 Answers4

Linked