extern int f(); VS int f();
Doug Gwyn
gwyn at smoke.BRL.MIL
Sun Feb 11 13:58:47 AEST 1990
In article <2912 at hcx1.SSD.CSD.HARRIS.COM> brad at SSD.CSD.HARRIS.COM (Brad Appleton) writes:
>Are the following function declarations equivalent?
>(1) extern int foo();
>(2) int foo();
>When would I use (1) and not (2) (and vice-versa)?
>Is this dependent on the Compiler Vendor?
>Is the answer different between ANSI-C and non-ANSI C?
This is a messy issue, because existing implementations differed in this.
The Standard situation for functions is simpler than for objects; the
latter involves the notion of "tentative definition" as well as linkage.
I'm just going to explain linkage here.
First, be sure you know the difference between object (data) and function.
Next, recall that there are four scopes of identifier visibility:
function-scope (labels only)
function-prototype scope (parameters in declarations only)
file-scope (declared outside blocks)
block-scope (declared inside a block, also parameters in
definitions)
Inner declarations can hide outer ones until the inner scope terminates.
Finally, linkage is determined as follows:
if not object and not function
or function parameter
or block-scope and object and not specified "extern"
then no linkage; done
fi
if function and no storage-class-specifier
then set storage-class-specifier to "extern"; proceed
fi
if specified "extern" { object or function }
then if there was a visible file-scope declaration
then linkage is same as visible file-scope's; done
else linkage is external; done
fi
fi
if file-scope
then case storage-class-specifier in
"static":
linkage is internal; done
none: { object }
linkage is external; done
esac
fi
If the same identifier has both internal and external linkage within
the same translation unit (source module including headers), the
behavior is undefined. If an identifier has no linkage, it is denotes
a unique entity. All instances of the same identifier with internal
linkage in the same translation unit denote the same object or function.
All instances of the same identifier with external linkage in the entire
program denote the same object or function.
Fortunately there is a simple set of rules the programmer can use to
avoid the "grey areas" of the linkage rules:
Always declare objects and functions that will be defined by
some other translation unit or library with explicit "extern".
Always define objects and functions that are published for
other translation units to use without a storage-class-specifier.
Always define functions and file-scope objects that are NOT
intended for use by other translation units with explicit "static".
If you're using a header file to define externally-visible
interfaces (a recommended practice), always use "extern" in its
object and function declarations (but not in type definitions).
>I am somewhat new to the net and would also appreciate some constructive
>feedback on whether this issue is worthy/appropriate for this newsgroup!
It's a legitimate question.
More information about the Comp.lang.c
mailing list