Re: Use of 'extern' keyword

On 28 Jul 2005 03:48:24 -0700, "Antonio Contreras" <anconor@xxxxxxxxx>
wrote in comp.lang.c:

> siliconwafer wrote:
> > 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.

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.
>
> > 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.

The rest of your advice is quite good.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html
.

Relevant Pages

  • Re: Static, Extern and Global
    ... If a function is defined with the 'static' keyword in front of its ... the name is not visible outside of the original source file. ... There is no 'Extern', or 'static' as you spelled it above. ... Everything defined at file scope in C or namespace scope in C++ has ...
    (alt.comp.lang.learn.c-cpp)
  • Re: extern variable assignment
    ... though keyword 'extern' serves no useful purpose here. ... If it is both a declaration and a definition, ...
    (microsoft.public.vc.language)
  • Re: Use of extern keyword
    ... > i.e consider a following piece of code from MSDN explaining extern ... > Here,if I drop the extern keyword from source file 2 and compile and ... of 'i' in the second source file, ... For reasons not worth going into here, on some compilers the program ...
    (comp.lang.c)
  • Re: Static allocation failure?
    ... There are three types of storage duration in a C program. ... ("automatic" is a keyword, too, but you never need it, so most people ... *) the opposite of "automatic" if used inside a block ... the correct thing would be for all data to be internal unless otherwise specified - such as by an "extern" declaration in the matching header file. ...
    (comp.arch.embedded)
  • Re: initialize the global variables in .so files
    ... I am facing one problem related to global variables in .so file. ... Now I used this global variable 'gserviceObj' to access the member ... gserviceObj;' declaration to main and change the all the other declarations in libraryto extern my application is working fine. ...
    (comp.unix.questions)