Use of 'extern' keyword

[siliconwafer]

Hi all,
I wanted to know that is use of extern keyword mandatory in case of
global variables and functions used in other source files?
i.e consider a following piece of code from MSDN explaining extern
storage class:
/******************************************************************
SOURCE FILE ONE
*******************************************************************/

extern int i; /* Reference to i, defined below */
void next( void ); /* Function prototype */

void main()
{
i++;
printf( "%d\n", i ); /* i equals 4 */
next();
}

int i = 3; /* Definition of i */

void next( void )
{
i++;
printf( "%d\n", i ); /* i equals 5 */
other();
}

/******************************************************************
SOURCE FILE TWO
*******************************************************************/

extern int i; /* Reference to i in */
/* first source file */
void other( void )
{
i++;
printf( "%d\n", i ); /* i equals 6 */
}


Here,if I drop the extern keyword from source file 2 and compile and
link the 2 source files I get the same result as with 'extern' keyword.
i.e extern keyword is optional.same is the case with functions.
If so in which cases is the use of 'extern' mandatory?
regards,
-Siliconwafer

 

[Antonio Contreras]

Hi all,
I wanted to know that is use of extern keyword mandatory in case of
global variables and functions used in other source files?
i.e consider a following piece of code from MSDN explaining extern
storage class:
/******************************************************************
SOURCE FILE ONE
*******************************************************************/

extern int i; /* Reference to i, defined below */
void next( void ); /* Function prototype */

void main()
{
i++;
printf( "%d\n", i ); /* i equals 4 */
next();
}

int i = 3; /* Definition of i */

void next( void )
{
i++;
printf( "%d\n", i ); /* i equals 5 */
other();
}

/******************************************************************
SOURCE FILE TWO
*******************************************************************/

extern int i; /* Reference to i in */
/* first source file */
void other( void )
{
i++;
printf( "%d\n", i ); /* i equals 6 */
}


Here,if I drop the extern keyword from source file 2 and compile and
link the 2 source files I get the same result as with 'extern' keyword.
i.e extern keyword is optional.

IIRC any declaration at file scope without an intialization is
considered to be a tentative declaration. This means that if the
compiler encounters the same variable declared more than once it fuses
all the ocurrences into a single global variable. In the case of gcc
you can force this situation to issue a warning. However, if you insist
in using global variables, it's much better practice to define the
variable just once and include it in a header file with the extern
keyword that can be conviniently included in other files as needed.

same is the case with functions.

A function that has no storage class specifier is considered to have
extern class, so they're visible in all compilation units unless
they're explicitly declared to be static, in wich case they're only
visible in the file they're declared.

If so in which cases is the use of 'extern' mandatory?

If you want some global variable defined in another file to be visible
just inside a function (or a block) then you need the extern keyword,
otherwise the declaration would be considered to be a local variable.
Ie:

File a.c:

int a = 0;

File b.c:

void func (void) {
extern int a;
....
}

HTH.

 

[Jack Klein]

IIRC any declaration at file scope without an intialization is
considered to be a tentative declaration. This means that if the
compiler encounters the same variable declared more than once it fuses
all the ocurrences into a single global variable.

Your recollection is partially correct, as far as the C standard is
concerned.

We are talking about declarations of objects at file scope without the
'static' keyword in a translation unit TU (roughly the source code
file and everything it includes). There are four possibilities:

1. Declaration includes 'extern' keyword and has no initializer.

2. Declaration includes 'extern' keyword and has an initializer.

3. Declaration does not have 'extern' keyword and has no initializer.

4. Declaration does not have 'extern' keyword and has an initializer.

Case 1 neither defines nor initializes the object, merely makes it
available for access by code in the TU where it appears. If the code
in the TU does actually reference the object, there must be a
definition of it provided elsewhere when the final program is
assembled. There may be multiple external declarations of this type
for the same object in a TU.

Cases 2 and 4, where an initializer is included in the elaboration,
are completely unambiguous and have exactly the same effect, namely
the definition of the object with external linkage. The presence or
absence of the 'extern' keyword makes no difference at all. This is
called an "external object definition". There may be exactly one such
external object definition of this type for an object in a TU.

Case 3 is the one that often causes confusion. When an object is
declared at file scope without the 'extern' keyword and without an
initializer, it is indeed called a "tentative definition". There may
be multiple tentative definitions of the same object in a TU.

Now here's exactly what the standard says about tentative definitions:

"If a translation unit contains one or more tentative definitions for
an identifier, and the translation unit contains no external
definition for that identifier, then the behavior is exactly as if the
translation unit contains a file scope declaration of that identifier,
with the composite type as of the end of the translation unit, with an
initializer equal to 0."

So the concept of "tentative definition" is only a temporary one
inside a translation unit. Any tentative definition of an object 'x'
will result in an external object definition for 'x', either one with
an initializer in the same translation unit, or an implicit:

object_type x = 0;

....generated by the compiler at the end of the translation unit.

In the OP's case, his first file contains an external object
definition of the int 'i' with an initial value of 3.

If he removes the 'extern' keyword the file scope declaration of 'i'
in the second file, it becomes a tentative definition which at the end
of the file is turned into an external object definition of the int
'i' with an initial value of 0.

If he combines both translation units into a single program, there are
two external object definitions for the int 'i'. This produces
undefined behavior as far as the C standard is concerned.

C has a simple rule for both objects and functions with external
linkage:

If the object or function is not actually referenced in the program,
there may be either 0 or 1 definitions of the object or function.

If the object or function is actually referenced in the program, it
must have exactly 1 external definition.

So omitting the 'extern' keyword from the declaration in the second
file produces undefined behavior. One possible result of undefined
behavior is the program is "working" as the programmer "expects". The
results with another compiler/linker tool set could be quite
different.

In the case of gcc
you can force this situation to issue a warning. However, if you insist
in using global variables, it's much better practice to define the
variable just once and include it in a header file with the extern
keyword that can be conviniently included in other files as needed.


A function that has no storage class specifier is considered to have
extern class, so they're visible in all compilation units unless
they're explicitly declared to be static, in wich case they're only
visible in the file they're declared.


If you want some global variable defined in another file to be visible
just inside a function (or a block) then you need the extern keyword,
otherwise the declaration would be considered to be a local variable.
Ie:

File a.c:

int a = 0;

File b.c:

void func (void) {
extern int a;
...
}

HTH.

The rest of your advice is quite good.

 

[Jack Klein]

Hi all,
I wanted to know that is use of extern keyword mandatory in case of
global variables and functions used in other source files?
i.e consider a following piece of code from MSDN explaining extern
storage class:
/******************************************************************
SOURCE FILE ONE
*******************************************************************/

extern int i; /* Reference to i, defined below */
void next( void ); /* Function prototype */

void main()

This is typical Microsoft arrogant, ignorant nonsense. Since they
don't claim conformance to the C standard later than 1995, what you
have when you start a program with "void main()" is totally undefined
behavior, therefore no longer actually a C program at all. At least
the C language standard says nothing at all about what it should or
will do.

But that does not really have anything to do with the issue you are
asking about.

{
i++;
printf( "%d\n", i ); /* i equals 4 */
next();
}

int i = 3; /* Definition of i */

void next( void )
{
i++;
printf( "%d\n", i ); /* i equals 5 */
other();
}

/******************************************************************
SOURCE FILE TWO
*******************************************************************/

extern int i; /* Reference to i in */
/* first source file */
void other( void )
{
i++;
printf( "%d\n", i ); /* i equals 6 */
}


Here,if I drop the extern keyword from source file 2 and compile and
link the 2 source files I get the same result as with 'extern' keyword.
i.e extern keyword is optional.same is the case with functions.
If so in which cases is the use of 'extern' mandatory?
regards,
-Siliconwafer

I went into detail about how the C standard defines this in my
response to Antonio Contreras's reply to your original post.

To summarize, if you remove the 'extern' keyword from the declaration
of 'i' in the second source file, you create an implicit external
definition of 'i' in that translation unit. The first source file has
an explicit external definition of 'i'. If you combine these into one
program, that program has two external definitions of 'i', and that
produces undefined behavior, which literally means that the C standard
washes its hands and doesn't say what should or will happen.

For reasons not worth going into here, on some compilers the program
will build and work the same if you remove the 'extern' keyword in the
second file. On other compilers you will get an error from the linker
and no executable file. I have even seen compilers that will create
different objects for each source file. Changes you make to 'i' in
one file will not change the value of 'i' in the other file.

So to answer your question about when you need the 'extern' keyword,
the C standard says you need it on every file scope declaration of an
object in all the source files of a program, with at most one
exception.

Regardless of how your particular version of your compiler treats this
particular example, if you want your program to build without error
and run with the same results on all C compilers, you need to have the
'extern' in the second file.

There are always dangers in assuming the requirements of the language
from the results of one compiler.

 

[siliconwafer]

Thanks Jack for such an elaborate reply.I found no book /web defination
that would clear the anamoly.
-Siliconwafer

 

[Kenny McCormack]

Thanks Jack for such an elaborate reply.I found no book /web defination
that would clear the anamoly.

I think we can all breathe a sigh of relief at that.

But what is a defination?

What is an anamoly?