What are extern variables in C?

Using extern is only of relevance when the program you're building consists of multiple source files linked together, where some of the variables defined, for example, in source file file1. C need to be referenced in other source files, such as file2. C .

Up vote 54 down vote favorite 62 share g+ share fb share tw.

The declaration, exact use of extern and its scope. C link|improve this question edited Sep 16 '09 at 14:48Jonathan Leffler139k10108268 asked Sep 16 '09 at 14:08shilpa.

3 Yes, probably, but it is also a legitimate question, and one for which the correct answer (hopefully mine as one of them) will help the asker to understand how to use C correctly and/or better. – Jonathan Leffler Sep 16 '09 at 14:49 1 See also stackoverflow.com/questions/683180/is-th... There may also be other relevant questions - there are a number of 'close but different enough not to count' questions that show up with a (SO) search on 'c extern' (typically, dealing with functions rather than variables). – Jonathan Leffler Sep 16 '09 at 15:05 @Jonathan: Here's the one I linked to: stackoverflow.com/questions/1410563 – sbi Sep 17 '09 at 14:56 @sbi: that covers one of the topics (declaration vs definition) nicely; it doesn't cover the extern issues as clearly as this question warrants.

Another related Q - but not a duplicate (and I don't think you were proposing it as a duplicate). – Jonathan Leffler Sep 17 '09 at 18:11 Nope, not duplicate. Yep, relevant.

:) – sbi Sep 18 '09 at 9:50.

Using extern is only of relevance when the program you're building consists of multiple source files linked together, where some of the variables defined, for example, in source file file1. C need to be referenced in other source files, such as file2.c. It is important to understand the difference between defining a variable and declaring a variable: A variable is defined when the compiler allocates the storage for the variable.

A variable is declared when the compiler is informed that a variable exists (and this is its type); it does not allocate the storage for the variable at that point. You may declare a variable multiple times (though once is sufficient); you may only define it once within a given scope. Best way to declare and define global variables Although there are other ways of doing it, the clean, reliable way to declare and define global variables is to use a header file file3.

H to contain an extern declaration of the variable. The header is included by the one source file that defines the variable and by all the source files that reference the variable. For each program, one source file (and only one source file) defines the variable.

Similarly, one header file (and only one header file) should declare the variable. File3. H extern int global_variable; /* Declaration of the variable */ file1.

C #include "file3. H" /* Declaration made available here */ /* Variable defined here */ int global_variable = 37; /* Definition checked against declaration */ int increment(void) { return global_variable++; } file2. C #include "file3.

H" #include void use_it(void) { printf("Global variable: %d\n", global_variable++); } That's the best way to use them. Guidelines Rules to be broken by experts only, and only with good reason: A header file only contains extern declarations of variables - never static or unqualified variable definitions. For any given variable, only one header file declares it (SPOT - Single Point of Truth).

A source file never contains extern declarations of variables - source files always include the (sole) header that declares them. For any given variable, exactly one source file defines the variable, preferably initializing it too. (Although there is no need to initialize explicitly to zero, it does no harm and can do some good, because there can be only one initialized definition of a particular global variable in a program).

The source file that defines the variable also includes the header to ensure that the definition and the declaration are consistent. A function should never need to declare a variable using extern. Avoid global variables whenever possible - use functions instead.

Not so good way to define global variables With some (indeed, many) C compilers, you can get away with what's called a 'common' definition of a variable too. 'Common', here, refers to a technique used in Fortran for sharing variables between source files, using a (possibly named) COMMON block. What happens here is that each of a number of files provides a tentative definition of the variable.

As long as no more than one file provides an initialized definition, then the various files end up sharing a common single definition of the variable: file10. C int i; /* Do not do this in portable code */ void inc(void) { i++; } file11. C int i; /* Do not do this in portable code */ void dec(void) { i--; } file12.

C int I = 9; /* Do not do this in portable code */ void put(void) { printf("i = %d\n", i); } This technique does not conform to the letter of the C standard and the 'one definition rule', but the C standard lists it as a common variation on its one definition rule. Because this technique is not always supported, it is best to avoid using it, especially if your code needs to be portable. Using this technique, you can also end up with unintentional type punning.

If one of the files declared I as a double instead of as an int, C's type-unsafe linkers probably would not spot the mismatch. If you're on a machine with 64-bit int and double, you'd not even get a warning; on a machine with 32-bit int and 64-bit double, you'd probably get a warning about the different sizes - the linker would use the largest size, exactly as a Fortran program would take the largest size of any common blocks. 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 noted in comments here, and as stated in my answer to a similar 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.

Violating the guidelines Note 1: if the header defines the variable without the extern keyword: faulty_header. H int some_var; /* Do not do this in a header! */ Then each file that includes the header creates a tentative definition of the variable.

Note 2: if the header defines and initializes the variable, then only one source file in a given program can use the header: broken_header. H int some_var = 13; /* Only one source file in a program can use this */ Note 3: if the header defines a static variable (with or without initialization), then each source file ends up with its own private version of the 'global' variable. Seldom_correct.

H static int hidden_global = 3; /* Each source file gets its own copy */ When the variable is actually a complex array, this can lead to extreme duplication of code. It can, very occasionally, be a sensible way to achieve some effect, but that is rather unusual. Use the header technique I showed first.

It works reliably and everywhere. Note, in particular, that the header declaring the global_variable is included in every file that uses it - including the one that defines it. This ensures that everything is self-consistent.

Similar concerns arise with declaring and defining functions - analogous rules apply. But the question was about variables specifically, so I've kept the answer to variables only. End of Original Answer Late Major Addition Avoiding Code Duplication One concern that is sometimes (and legitimately) raised about the 'declarations in headers, definitions in source' mechanism described here is that there are two files to be kept synchronized - the header and the source.

This is usually followed up with an observation that a macro can be used so that the header serves double duty - normally declaring the variables, but when a specific macro is set before the header is included, it defines the variables instead. Another concern can be that the variables need to be defined in each of a number of 'main programs'. This is normally a spurious concern; you can simply introduce a C source file to define the variables and link the object file produced with each of the programs.

A typical scheme works like this, using the original global variable illustrated in file3. H: file3a. H #ifdef DEFINE_VARIABLES #define EXTERN /* nothing */ #else #define EXTERN extern #endif /* DEFINE_VARIABLES */ EXTERN int global_variable; file1a.

C #define DEFINE_VARIABLES #include "file3a. H" /* Variable defined - but not initialized */ int increment(void) { return global_variable++; } file2a. C #include "file3a.

H" #include void use_it(void) { printf("Global variable: %d\n", global_variable++); } The problem with this scheme as shown is that it does not provide for initialization of the global variable. With C99 and variable argument lists for macros, you could define macros to support initialization too. You probably need two such macros, one for simple initializers with no commas, and a second for complex initializers containing commas: file3b.

H #ifdef DEFINE_VARIABLES #define EXTERN extern #define INIT_SIMPLE(x) /* nothing */ #define INIT_COMPLEX(x, ...) /* nothing */ #else #define EXTERN /* nothing */ #define INIT_SIMPLE(x) = x #define INIT_COMPLEX(x, ...) = x, __VA_ARGS__ #endif /* DEFINE_VARIABLES */ EXTERN int global_variable INIT_SIMPLE(37); EXTERN struct { int a; int b; } oddball_struct INIT_COMPLEX({ 41, 43 }); file1b. C #define DEFINE_VARIABLES #include "file3b. H" /* Variables now defined and initialized */ int increment(void) { return global_variable++; } int oddball_value(void) { return oddball_struct.

A + oddball_struct. B; } file2b. C #include "fileba.

H" #include void use_them(void) { printf("Global variable: %d\n", global_variable++); oddball_struct. A += global_variable; oddball_struct. B -= global_variable / 2; } Clearly, the code for the oddball structure is not what you'd normally write, but it illustrates the point.

The first argument to INIT_COMPLEX is { 41 and the remaining argument (singular in this example) is 43 }. Without C99 or similar support for variable argument lists for macros, initializers that need to contain commas are very problematic. Header Guards Any header should be protected against reinclusion, so that type definitions (enum, struct or union types, or typedefs generally) do not cause problems.

The standard technique is to wrap the body of the header in a header guard: #ifndef FILE3B_H_INCLUDED #define FILE3B_H_INCLUDED ...contents of header... #endif /* FILE3B_H_INCLUDED */ The header might be included twice indirectly. For example, if file4b. H includes file3b.

H for a type definition that isn't shown, and file1b. C needs to use both header file4b. H and file3b.

H, then you have some more tricky issues to resolve. Clearly, you might revise the header list to include just file4b.h. However, you might not be aware of the internal dependencies - and the code should, ideally, continue to work.

Further, it starts to get tricky because you might include file4b. H before including file3b. H to generate the definitions, but the normal header guards on file3b.

H would prevent the header being reincluded. So, you need to include the body of file3b. H at most once for declarations, and at most once for definitions, but you might need both in a single translation unit (TU - a combination of a source file and the headers it uses).

Multiple inclusion with variable definitions However, it can be done subject to a not too unreasonable constraint. Let's introduce a new set of file names: external. H for the EXTERN macro definitions, etc. file1c.

H to define types (notably, struct oddball, the type of oddball_struct). File2c. H to define or declare the global variables.

File3c. C which defines the global variables. File4c.

C which simply uses the global variables. File5c. C which shows that you can declare and then define the global variables.

File6c. C which shows that you can define and then (attempt to) declare the global variables. In these examples, file5c.

C and file6c. C directly include the header file2c. H several times, but that is the simplest way to show that the mechanism works.

It means that if the header was indirectly included twice, it would also be safe. The restrictions for this to work are: The header defining or declaring the global variables may not itself define any types. Immediately before you include a header that should define variables, you define the macro DEFINE_VARIABLES.

The header defining or declaring the variables has stylized contents. External. H /* ** This header must not contain header guards (like must not).

** Each time it is invoked, it redefines the three macros EXTERN, ** INIT_SIMPLE, INIT_COMPLEX based on whether macro DEFINE_VARIABLES is ** currently defined. */ #undef EXTERN #undef INIT_SIMPLE #undef INIT_COMPLEX #ifdef DEFINE_VARIABLES #define EXTERN extern #define INIT_SIMPLE(x) /* nothing */ #define INIT_COMPLEX(x, ...) /* nothing */ #else #define EXTERN /* nothing */ #define INIT_SIMPLE(x) = x #define INIT_COMPLEX(x, ...) = x, __VA_ARGS__ #endif /* DEFINE_VARIABLES */ file1c. H #ifndef FILE1C_H_INCLUDED #define FILE1C_H_INCLUDED struct oddball { int a; int b; }; extern void use_them(void); extern int increment(void); extern int oddball_value(void); #endif /* FILE1C_H_INCLUDED */ file2c.

H /* Standard prologue */ #if defined(DEFINE_VARIABLES) &&! Defined(FILE2C_H_DEFINITIONS) #undef FILE2C_H_INCLUDED #endif #ifndef FILE2C_H_INCLUDED #define FILE2C_H_INCLUDED #include "external. H" /* Support macros EXTERN, INIT_SIMPLE, INIT_COMPLEX */ #include "file1c.

H" /* Type definition for struct oddball */ /* Global variable declarations / definitions */ EXTERN int global_variable INIT_SIMPLE(37); EXTERN struct oddball oddball_struct INIT_COMPLEX({ 41, 43 }); /* Standard epilogue */ #ifdef DEFINE_VARIABLES #define FILE2C_H_DEFINITIONS #undef DEFINE_VARIABLES /* Safety first */ #endif /* DEFINE_VARIABLES */ #endif /* FILE2C_H_INCLUDED */ file3c. C #define DEFINE_VARIABLES #include "file2c. H" /* Variables now defined and initialized */ int increment(void) { return global_variable++; } int oddball_value(void) { return oddball_struct.

A + oddball_struct. B; } file4c. C #include "file2c.

H" #include void use_them(void) { printf("Global variable: %d\n", global_variable++); oddball_struct. A += global_variable; oddball_struct. B -= global_variable / 2; } file5c.

C #include "file2c. H" /* Declare variables */ #define DEFINE_VARIABLES #include "file2c. H" /* Variables now defined and initialized */ int increment(void) { return global_variable++; } int oddball_value(void) { return oddball_struct.

A + oddball_struct. B; } file6c. C #define DEFINE_VARIABLES #include "file2c.

H" /* Variables now defined and initialized */ #include "file2c. H" /* Declare variables */ int increment(void) { return global_variable++; } int oddball_value(void) { return oddball_struct. A + oddball_struct.

B; } This scheme avoids most problems. You only run into a problem if a header that defines variables (such as file2c. H) is included by another header (say file7c.

H) that defines variables. There isn't an easy way around that other than "don't do it". You can partially work around the problem by revising file2c.

H to: file2c. H - revised /* Standard prologue */ #if defined(DEFINE_VARIABLES) &&! Defined(FILE2C_H_DEFINITIONS) #undef FILE2C_H_INCLUDED #endif #ifndef FILE2C_H_INCLUDED #define FILE2C_H_INCLUDED #include "external.

H" /* Support macros EXTERN, INIT_SIMPLE, INIT_COMPLEX */ #include "file1c. H" /* Type definition for struct oddball */ #if! Defined(DEFINE_VARIABLES) ||!

Defined(FILE2C_H_DEFINITIONS) /* Global variable declarations / definitions */ EXTERN int global_variable INIT_SIMPLE(37); EXTERN struct oddball oddball_struct INIT_COMPLEX({ 41, 43 }); #endif /*! DEFINE_VARIABLES ||! FILE2C_H_DEFINITIONS */ /* Standard epilogue */ #ifdef DEFINE_VARIABLES #define FILE2C_H_DEFINITIONS #undef DEFINE_VARIABLES /* See discussion below */ #endif /* DEFINE_VARIABLES */ #endif /* FILE2C_H_INCLUDED */ The issue becomes 'should the header include #undef DEFINE_VARIABLES?

' If you omit that from the header and wrap any defining invocation with #define and #undef: #define DEFINE_VARIABLES #include "file2c. H" #undef DEFINE_VARIABLES in the source code (so the headers never alter the value of DEFINE_VARIABLES, then you should be clean. It is just a nuisance to have to remember to write the the extra line.

An alternative might be: #define HEADER_DEFINING_VARIABLES "file2c. H" #include "externdef. H" where externdef.

H contains: #if defined(HEADER_DEFINING_VARIABLES) #define DEFINE_VARIABLES #include HEADER_DEFINING_VARIABLES #undef DEFINE_VARIABLES #undef HEADER_DEFINING_VARIABLES #endif /* HEADER_DEFINING_VARIABLES */ This is getting a tad convoluted, but seems to be secure (using the revised version of file2c. H, and with no #undef DEFINE_VARIABLES in the file2c. H).

File7c. C /* Declare variables */ #include "file2c. H" /* Define variables */ #define HEADER_DEFINING_VARIABLES "file2c.

H" #include "externdef. H" /* Declare variables - again */ #include "file2c. H" /* Define variables - again */ #define HEADER_DEFINING_VARIABLES "file2c.

H" #include "externdef. H" int increment(void) { return global_variable++; } int oddball_value(void) { return oddball_struct. A + oddball_struct.

B; } file8c. H /* Standard prologue */ #if defined(DEFINE_VARIABLES) &&! Defined(FILE8C_H_DEFINITIONS) #undef FILE8C_H_INCLUDED #endif #ifndef FILE8C_H_INCLUDED #define FILE8C_H_INCLUDED #include "external.

H" /* Support macros EXTERN, INIT_SIMPLE, INIT_COMPLEX */ #include "file2c. H" /* struct oddball */ #if! Defined(DEFINE_VARIABLES) ||!

Defined(FILE8C_H_DEFINITIONS) /* Global variable declarations / definitions */ EXTERN struct oddball another INIT_COMPLEX({ 14, 34 }); #endif /*! DEFINE_VARIABLES ||! FILE8C_H_DEFINITIONS */ /* Standard epilogue */ #ifdef DEFINE_VARIABLES #define FILE8C_H_DEFINITIONS #endif /* DEFINE_VARIABLES */ #endif /* FILE8C_H_INCLUDED */ file8c.

C /* Define variables */ #define HEADER_DEFINING_VARIABLES "file2c. H" #include "externdef. H" /* Define variables */ #define HEADER_DEFINING_VARIABLES "file8c.

H" #include "externdef. H" int increment(void) { return global_variable++; } int oddball_value(void) { return oddball_struct. A + oddball_struct.

B; } However, the problems are relatively unlikely to occur in practice, especially if you take the standard advice to Avoid global variables Does this exposition miss anything? Confession: The 'avoiding duplicated code' scheme outlined here was developed because the issue affects some code I work on (but don't own), and is a niggling concern with the scheme outlined in the first part of the answer. However, the original scheme leaves you with just two places to modify to keep variable definitions and declarations synchronized, which is a big step forward over having exernal variable declarations scattered throughout the code base (which really matters when there are thousands of files in total).

However, the code in the files with the names fileNc. Ch (plus external. H and externdef.

H) shows that it can be made to work. Clearly, it would not be hard to create a header generator script to give you the standardized template for a variable defining and declaring header file.

Er, with the composite type as of the end of the translation unit, with an initializer equal to 0. " – Johannes Schaub - litb Sep 16 '09 at 15:03 1 @litb: see Annex J. 5.11 for the common definition - it is a common extension.

– Jonathan Leffler Sep 16 '09 at 15:19 1 @litb: and I agree it should be avoided - that's why it is in the section on 'Not so good way to define global variables'. – Jonathan Leffler Sep 16 '09 at 15:20 2 Indeed it's a common extension, but it's undefined behavior for a program to rely on it. I just wasn't clear whether you were saying that this is allowed by C's own rules.

Now I see you are saying it's just a common extension and to avoid it if you need your code to be portable. So I can upvote you without doubts. Really great answer IMHO :) – Johannes Schaub - litb Sep 16 '09 at 15:30 2 @Johnathan: Great answer.

– Paul Nathan Sep 16 '09 at 16:01.

Extern tells the compiler to trust you that the memory for this variable is declared elsewhere, so it doesn't try to allocate/check memory. Therefore, you can compile a file that has reference to an extern, but you can not link if that memory is not declared somewhere. Useful for global variables and libraries, but dangerous because the linker does not type check.

The memory isn't declared. See the answers to this question: stackoverflow.com/questions/1410563 for more details. – sbi Sep 16 '09 at 14:37.

Extern is the keyword you use to declare that the variable itself resides in another translation unit. So you can decide to use a variable in a translation unit and then access it from another one, then in the second one you declare it as extern and the symbol will be resolved by the linker. If you don't declare it as extern you'll get 2 variables named the same but not related at all, and an error of multiple definitions of the variable.

2 In other words the translation unit where extern is used knows about this variable, its type etc. and hence allows the source code in the underlying logic to use it, but it does not allocate the variable, another translation unit will do that. If both translation units were to declare the variable normally, there would be effectily two physical locations for the variable, with the associated "wrong" references within the compiled code, and with the resulting ambiguity for the linker. – mjv Sep 16 '09 at 14:19.

A extern variable is a declaration (thanks to sbi for the correction) of a variable which is defined in another translation unit. So that means that the variable is defined in another file... Say you have to . C-files test1.

C and test2.c. If you define a global variable int test1_var; in test1. C and you'd like to access this variable in test2.

C you have to use extern int test1_var; in test2.c. Complete sample: $cat test1. C int test1_var = 5; $cat test2.

C #include extern int test1_var; int main() { printf("test1_var = %d\n", test1_var); } $gcc test1. C test2. C -o test $.

/test test1_var = 5.

2 There's no "pseudo-definitions". It's a declaration. – sbi Sep 16 '09 at 14:18 thanks, corrected – Johannes Weiß Sep 16 '09 at 14:25.

I like to think of an extern variable as a promise that you make to the compiler. When encountering an extern, the compiler can only find out its type, not where it "lives", so it can't resolve the reference. You are telling it, "Trust me.

At link time this reference will be resolvable.

More generally, a declaration is a promise that the name will be resolvable to a exactly one definition at link time. An extern declares a variable without defining. – Lie Ryan Nov 30 '10 at 2:16.

Adding an extern turns a variable definition into a variable declaration. See this thread as to what's the difference between a declaration and a definition.

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.