Tentative definitions in C and linking

35
votes

Consider the C program composed of two files,

f1.c:

int x;

f2.c:

int x=2;

My reading of paragraph 6.9.2 of the C99 standard is that this program should be rejected. In my interpretation of 6.9.2, variable x is tentatively defined in f1.c, but this tentative definition becomes an actual definition at the end of the translation unit, and (in my opinion), should therefore behave as if f1.c contained the definition int x=0;.

With all compilers (and, importantly, linkers) I was able to try, this is not what happens. All compilation platforms I tried do link the above two files, and the value of x is 2 in both files.

I doubt this happens by accident, or just as an "easy" feature to provide in addition to what the standard requires. If you think about it, it means there is special support in the linker for those global variables that do not have an initializer, as opposed to those explicitly initialized to zero. Someone told me that the linker feature may be necessary to compile Fortran anyway. That would be a reasonable explanation.

Any thoughts about this? Other interpretations of the standard? Names of platforms on which files f1.c and f2.c refuse to be linked together?

Note: this is important because the question occurs in the context of static analysis. If the two files may refuse to be linked on some platform, the analyzer should complain, but if every compilation platform accepts it then there is no reason to warn about it.

3
ccompilationfortranstatic-analysisc99
Thanks for sharing. never too old to learn – Adriaan
The compiler need to reject (i.e warn or error) things only when you violate things in a constraint paragraph. The constraint that you may not have two external definitions for your things is a "shall" outside a constraint paragraph. Violating any shall outside a constraint automatically results in undefined behavior in C - that's what grants the compiler to treat it like it wants. – Johannes Schaub - litb
@litb That's an interesting point. The static analyzer I mentioned tries, when possible, not to flag /established/ programming practices even when they are not defined by the standard. Here, I think we will decide not to warn, since on a platform on which these multiple definitions are not supported, probably they would result in a failure at link-time, not run-time. PS:I know what "undefined" means but each additional analysis option make the analyzer a little less usable, and that must be weighted against the gains. Hence the "Names of platforms on which..." part of the question – Pascal Cuoq
Recent gcc versions use -fno-common by default. Then you will get a linker error even if you just have int x; without initialization in f2.c. Merging tentative definitions across compilation units is bad, IMHO. It will lead to bugs. The extern keyword exists now to do things properly. – Sven

3 Answers

30
votes

See also What are extern variables in C. This is mentioned in the C standard in informative Annex J as a common extension:

J.5.11 Multiple external definitions

There may be more than one external definition for the identifier of an object, with or without the explicit use of the keyword extern; if the definitions disagree, or more than one is initialized, the behavior is undefined (6.9.2).

Warning

As @litb points out here, and as stated in my answer to the cross-referenced question, using multiple definitions for a global variable leads to undefined behaviour, which is the standard's way of saying "anything could happen". One of the things that can happen is that the program behaves as you expect; and J.5.11 says, approximately, "you might be lucky more often than you deserve". But a program that relies on multiple definitions of an extern variable - with or without the explicit 'extern' keyword - is not a strictly conforming program and not guaranteed to work everywhere. Equivalently: it contains a bug which may or may not show itself.

11
votes

There is something called a "common extension" to the standard, where defining variables multiple times is allowed as long as the variable is initialized only once. See http://c-faq.com/decl/decldef.html

The linked page says this is pertinent to Unix platforms--I guess it's the same for c99 as c89--though maybe it has been adopted by more compilers to form some sort of a defacto standard. Interesting.

7
votes

This is to clarify my answer to a comment by olovb:

output of nm for an object file compiled from "int x;". On this platform, symbols are prepended with a '_', that is, the variable x appears as _x.

00000000 T _main
         U _unknown
00000004 C _x
         U dyld_stub_binding_helper

output of nm for an object file compiled from "int x=1;"

00000000 T _main
         U _unknown
000000a0 D _x
         U dyld_stub_binding_helper

output of nm for an object file compiled from "int x=0;"

00000000 T _main
         U _unknown
000000a0 D _x
         U dyld_stub_binding_helper

output of nm for an object file compiled from "extern int x;"

00000000 T _main
         U _unknown
         U dyld_stub_binding_helper

EDIT: output of nm for an object file compiled from "extern int x;" where x is actually used in one of the functions

00000000 T _main
         U _unknown
         U _x
         U dyld_stub_binding_helper