No warning with uninitialized C string

Question

I'm currently wondering why I don't get an error from GCC during compilation/linking of a small C program.

I declared in version.h the following string:

const char* const VERSION;

In version.c I have set the initialization of the variable:

const char* const VERSION = "0.8 rev 213";

No problem with that. I can use the string in the rest of the program.

If the c file is missing, no error occurs during compilation/linking but the program fails with SIGSEGV (of course) when it tries to access the variable.

Is my way of setting up the variable VERSION correct or is there a better way? Or is there a chance to get an error during compilation/linking?

your .h file should declare the variable as "extern". (extern const char * const VERSION;) — Ronald, Jul 02 '18 at 11:46
This declared two different variables with the same name, which is (oddly) ok to do in C within the same translation unit - then and only then they refer to the same variable. But it does not work across several translation units. You'd end up with different versions of VERSION. — Lundin, Jul 02 '18 at 11:50
@Lundin I think that would be true in C++, where a `const` declaration not previously declared otherwise has internal linkage. But in C, the default is external linkage, `const` or not. — aschepler, Jul 02 '18 at 12:09
@Lundin In practice, it works with almost all C environments used in the wild. — Ctx, Jul 02 '18 at 12:15
@aschepler C++ wouldn't allow a const variable which isn't initialized though, which C (stupidly) allows. — Lundin, Jul 02 '18 at 12:24
@Lundin Not stupid in C. Objects may be declared multiple times in a scope, and each declaration must match the definition, `const` and all. Stroustrup started out with a different idea of what `const` should mean; and that morphed back into something more compatible with ANSI C later. That's where the weird rule about default internal linkage comes from. — Mike Housky, Jul 02 '18 at 12:49

score 30 · Accepted Answer · edited Jun 20 '20 at 09:12

30

You have defined (not just declared) a variable in the header.

If you ever include this header from more than one source file, the behaviour is undefined. Here's the relevant quote from the standard:

J.2 Undefined behavior

…

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.

…

You are relying on a GCC-specific (actually common to many compilers, but still non-standard) behaviour here, which is merging of duplicate tentative data definitions. See help for -fcommon and -fno-common GCC compilation flags. Not all compilers behave this way. Historically this is the common behaviour for linkers, because that's how Fortran worked before there was C.

Assuming this language extension, one of the definitions (one that has an explicit initializer) initialises the variable to point to your string literal. But if you omit this definition, it will remain zero-initialised. That is, it will be a constant null pointer. Not very useful.

To make long story short, never ever do that. In order to declare (but not define) a global variable in a header, use extern. If you do, and try to omit a definition elsewhere, you will likely get a linker error (though the standard does not require diagnostic for this violation, all known implementation produce one).

edited Jun 20 '20 at 09:12

Community

1
1

answered Jul 02 '18 at 11:54

n. m. could be an AI

112,515
14
128
243

It's not undefined. It's perfectly well defined, except just in C, but not C++. – Petr Skocik Jul 02 '18 at 12:32
@PSkocik I don't think so. Tentative definitions are irrelevant, because they are only tentative to the end of a TU, at which point they become normal definitions. – n. m. could be an AI Jul 02 '18 at 13:22
Looks like you're right. Couldn't find anything in the standard about tentative definitions and multiple TUs so I guess that'd make it undefined – Petr Skocik Jul 02 '18 at 13:27
@PSkocik Updated the answer with the relevant quote from the standard. – n. m. could be an AI Jul 02 '18 at 13:31
1

Thanks. Used it to turn my downvote into an upvote. ;) – Petr Skocik Jul 02 '18 at 13:34
1

See the discussion of [C11 Appendix J.5.11 Multiple external definitions](http://port70.net/~nsz/c/c11/n1570.html#J.5.11) in [How do I use `extern` to share variables between source files](https://stackoverflow.com/q/1433204/15168). It is not conforming to the letter of the C standard, but it is a recognized commonly implemented extension that normally works on Unix-like systems (and is not restricted to GCC) — but isn't guaranteed to work anywhere by the standard. – Jonathan Leffler Jul 02 '18 at 18:09

Petr Skocik · Answer 2 · 2018-07-02T13:32:05.063

Your example works because of a Fortran-inspired (mis)feature of C (but not C++) called tentative definitions (6.9.2p2) which is commonly but nonstandardly extended to multiple files.

Tentative definitions are variable declarations without extern and with no initializer. In common implementations (pun intended), tentative definitions create a special kind of symbol which is called a common symbol. During linking, in the presence of a regular symbol of the same name, other common symbols become references to the regular symbol which means all the empty VERSIONs in your translation units created there due to inclusions will become references to the regular symbol const char* const VERSION = "0.8 rev 213";. If there's no such regular symbol, the common symbols will get merged into a single zero-initalized variable.

I don't know how to get a warning against this with a C compiler.

This

const char* const VERSION;
const char* const VERSION = "0.8 rev 213";

seems to work with gcc no matter what I've tried (g++ won't accept it -- C++ doesn't have the tentative definition feature and it doesn't like const variables that aren't explicitly initialized). But you can compile with -fno-common (which is a fairly "common" (and highly recommended) nonstandard option (gcc,clang, and tcc all have it)) and then you will get a linker error if the non-initialized and the initialized extern-less declarations are in different translation units.

Example:

v.c:

const char * VERSION;

main.c

const char* VERSION;
int main(){}

compilation and linking:

gcc main.c v.c #no error because of tentative definitions
g++ main.c v.c #linker error because C++ doesn't have tentative definitions
gcc main.c v.c -fno-common #linker error because tentative defs. are disabled

(I removed the second const in the example for the sake of the C++ example — C++ additionally makes const globals static or something like that which only complicates the demonstration of the tentative definition feature.)

With tentative definitions disabled or with C++, all your variable declarations in headers should have extern in them

version.h:

extern const char* const VERSION;

and you should have exactly one definition for each global and that definition should have an initializer or be without extern (some compilers will warn if you apply extern to an initialized variable).

version.c:

#include "version.h" //optional; for type checking
const char* const VERSION = "0.8 rev 213";

*common implementations (pun intended), tentative definitions create a special kind of symbol which is called a common symbol* This is how implementations behave indeed, but that's exactly what the standar does NOT say. *-fno-common nonstandard option* `man gcc` seems to have a different opinion about which of `-fcommon` and `-fno-common` requests non-standard behaviour. — n. m. could be an AI, Jul 02 '18 at 13:19

Achal · Answer 3 · 2018-07-02T13:43:51.430

6

In version.h you should declare VERSION as a extern like

extern const char* const VERSION;

And in version.c you should define the extern variable like

const char* const VERSION = "0.8 rev 213";

EDIT :- Also you need to make sure that only one source file defined the variable VERSION while the other source files declared it extern and you can do it by defining it in a source file VERSION.c and put the extern declaration in a header file VERSION.h.

edited Jul 02 '18 at 13:43

answered Jul 02 '18 at 11:56

Achal

11,821
2
15
37

I'd like to make that the answer for the question, but actually the extra information given by n.m. in his/her answer should be included as well INMHO ... – Max Senft Jul 02 '18 at 12:05

No warning with uninitialized C string

3 Answers3

J.2 Undefined behavior