Inclusion of unused symbols in object files by compiler in C vs C++

c, c++, compilation

Solution

In C, identifiers have three different types of "linkage":

- external linkage: roughly, this is what people mean by "global variables". In common terms, it refers to identifiers that are visible "everywhere".

- internal linkage: these are objects that are declared with `static` keyword.

- no linkage: these are objects that are "temporary", or "automatic", such as variables declared inside a function (commonly referred as "local variables").

For objects with external linkage, you can have only one definition. Since your header file defines such an object and is included in two C files, it is undefined behavior (but see below). The fact that your C compiler doesn't complain does not mean it is OK to do so in C. For this, you must read the C standard. (Or, assuming no bugs in your compiler, if it is invoked in a standards-compliant mode, and if it complains about something [gives a diagnostic], it probably means your program isn't compliant.)

In other words, you can't test what is allowed by the language by testing something and checking if your compiler allows it. For this, you must read the standard.

Note that there is a subtle difference between definition and tentative definition.

$ cat a.c
int x = 0;
$ cat b.c
#include <stdio.h>
int x = 0;
int main(void)
{
    printf("%d\n", x);
    return 0;
}
$ gcc -ansi -pedantic -W -Wall -c a.c
$ gcc -ansi -pedantic -W -Wall -c b.c
$ gcc -o def a.o b.o
b.o:(.bss+0x0): multiple definition of `x'
a.o:(.bss+0x0): first defined here
collect2: ld returned 1 exit status

Now, let's change `a.c`:

$ cat a.c
int x; /* Note missing " = 0", so tentative definition */

Now compile it:

$ gcc -ansi -pedantic -W -Wall -c a.c
$ gcc -o def a.o b.o
$ ./def
0

We can change `b.c` instead:

$ cat a.c
int x = 0;
$ cat b.c
#include <stdio.h>
int x; /* tentative definition */
int main(void)
{
    printf("%d\n", x);
    return 0;
}
$ gcc -ansi -pedantic -W -Wall -c a.c
$ gcc -ansi -pedantic -W -Wall -c b.c
$ gcc -o def a.o b.o
$ ./def
0

A "tentative definition" becomes "real definition" in C if there is no other definition. So, we could have changed both files to contain `int x;`, and it would be legal C.

So, you may have a tentative definition in the header file. We need to see the actual code to be sure.

The C standard says that the following is undefined behavior (appendix J.2p1):

An identifier with external linkage is used, but in the program there does not exist exactly one external definition for the identifier, or the identifier is not used and there exist multiple external definitions for the identifier.

C++ may have different rules.

Edit: As per this thread on `comp.lang.c++`, C++ does not have tentative definitions. The reason being:

This avoids having different initialization rules for built-in types and user-defined types.

(The thread deals with the same question, btw.)

Now I am almost sure that OP's code contains what C calls "tentative definition" in the header file, which makes it legal in C and illegal in C++. We will know for sure only when we see the code though.

More information on "tentative definitions" and why they are needed is in this excellent post on comp.lang.c (by Chris Torek).

Problem

This might be a dumb question, but maybe someone can provide some insight. I have some global variables defined in a header file (yes yes I know that's bad, but this is just a hypothetical situation). I include this header file in two source files, which are then compiled into two object files. The global symbols are not referenced anywhere in the code. If the source files are C, then it looks like the compiler omits the global symbols and everything links without errors. If the source files are C++, the symbols are included in both object files and then I get linker errors. For C++ I am using extern "C" when I include the header. I am using the Microsoft compiler from VS2005. Here is my code: Header file (test.h): ``` #ifndef __TEST_H #define __TEST_H /* declaration in header file */ void *ptr; #endif ``` C Source files: test1.c ``` #include "test.h" int main( ) { return 0; } ``` test2.c ``` #include "test.h" ``` C++ Source Files: test1.cpp ``` extern "C" { #include "test.h" } int main( ) { return 0; } ``` test2.cpp ``` extern "C" { #include "test.h" } ``` For C, the object files look something like this: ``` Dump of file test1.obj File Type: COFF OBJECT COFF SYMBOL TABLE 000 006DC627 ABS notype Static | @comp.id 001 00000001 ABS notype Static | @feat.00 002 00000000 SECT1 notype Static | .drectve Section length 2F, #relocs 0, #linenums 0, checksum 0 004 00000000 SECT2 notype Static | .debug$S Section length 228, #relocs 7, #linenums 0, checksum 0 006 00000004 UNDEF notype External | _ptr 007 00000000 SECT3 notype Static | .text Section length 7, #relocs 0, #linenums 0, checksum 96F779C9 009 00000000 SECT3 notype () External | _main 00A 00000000 SECT4 notype Static | .debug$T Section length 1C, #relocs 0, #linenums 0, checksum 0 String Table Size = 0x0 bytes ``` And for C++ they look something like this: ``` Dump of file test1.obj File Type: COFF OBJECT COFF SYMBOL TABLE 000 006EC627 ABS notype Static | @comp.id 001 00000001 ABS notype Static | @feat.00 002 00000000 SECT1 notype Static | .drectve Section length 2F, #relocs 0, #linenums 0, checksum 0 004 00000000 SECT2 notype Static | .debug$S Section length 228, #relocs 7, #linenums 0, checksum 0 006 00000000 SECT3 notype Static | .bss Section length 4, #relocs 0, #linenums 0, checksum 0 008 00000000 SECT3 notype External | _ptr 009 00000000 SECT4 notype Static | .text Section length 7, #relocs 0, #linenums 0, checksum 96F779C9 00B 00000000 SECT4 notype () External | _main 00C 00000000 SECT5 notype Static | .debug$T Section length 1C, #relocs 0, #linenums 0, checksum 0 String Table Size = 0x0 bytes ``` I notice that _ptr is listed as UNDEF when I compile the C source, and it is defined when I compile the C++ source, which results in linker errors. I understand that this is not a good thing to do in real life, I am just trying to understand why this is different. Thanks.

Original source