extern

[Flash Gordon]

Re: extern

Chris Torek wrote:[color=blue]
> In article <sysDe.184979$7 5.8009312@news4 .tin.it>
> DevarajA <no@spam.com> wrote:
>[color=green]
>>I compiled into an object file (on linux) with:
>>$ gcc a.c -c -o a.obj
>>and then i printed it's symbol table with:
>>$ nm a.obj
>>This is the output:
>>
>>00000000 T main
>>00000004 C var2
>>
>>where "C" means "The symbol is common. ...[/color]
>
>
> The so-called "common model", in which var2 uses this "common
> symbol" trick, is *optional*: C compilers are not required to
> implement one. They may instead use a "def/ref model".
>
> If your C compiler used a def/ref model, the "nm" output for the
> above would give var2 the "D" type. Changing the declaration
> for var2 to "extern int var2" would give it the "U" type.
>
> C compilers on Unix-like systems never use the def/ref model,[/color]

Not true, Chris. If you give gcc the correct command line options on a
Unixlike implementation (Linux) it will not use the common model and
*will* generate an error on linking if a variable is declared twice even
with neither declaration specifying an initialiser.
[color=blue]
> because there are gigabytes of Unix-like-system "freeware" source
> code that *require* common-model. C compilers on some other systems
> *do* use def/ref, and that code fails to compile on them.[/color]

That I can believe, since gcc probably has the same option on non-unix
like systems ;-)
[color=blue]
> (C++
> compilers also do use def/ref, even on Unix-like systems.)[/color]

That I can't comment on.
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.

[Chris Torek]

Re: extern

>Chris Torek wrote:[color=blue][color=green]
>> C compilers on Unix-like systems never use the def/ref model ...[/color][/color]

In article <o243r2xd21.ln2 @brenda.flash-gordon.me.uk>
Flash Gordon <spam@flash-gordon.me.uk> wrote:[color=blue]
>Not true, Chris. If you give gcc the correct command line options on a
>Unixlike implementation (Linux) it will not use the common model and
>*will* generate an error on linking if a variable is declared twice even
>with neither declaration specifying an initialiser.[/color]

OK, make that "never use def/ref by default." :-)

The (ancient, way-before-C89) C compiler that really annoyed me
was Whitesmiths C for the Z80, which treated:

int a;

and

extern int a;

as meaning exactly the same thing: "a" was "ref"d but not "def"d.
You *had* to write:

int a = 0;

to get the variable defined. During the winter holiday between
1981 and 1982, I did a consulting job, porting a Votrax text-to-speech
program from PL/M to C, using this compiler. I spent about a day
trying to figure out why some variables were undefined, and others
were defined, when they were all carefully defined exactly once,
and "extern"ed everywhere else. It turned out Whitesmiths C did
not even implement the K&R White-book language.

(I ended up creating a source file consisting of:

int switch_a = 0;
char *option_b = NULL;

and so on, for all the variables that were otherwise uninitialized.)

(The library also lacked most of the usual functions, such as
printf(). Fortunately printf() was not a lot of use in this
particular freestanding system, since the point was to speak for
a blind programmer, not print on a screen.)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[Mark McIntyre]

Re: extern

On Wed, 20 Jul 2005 13:39:13 +0100, in comp.lang.c , Lawrence Kirby
<lknews@netacti ve.co.uk> wrote:
[color=blue]
>On Wed, 20 Jul 2005 12:03:08 +0100, Mark McIntyre wrote:
>[color=green]
>> On Tue, 19 Jul 2005 21:43:12 -0500, in comp.lang.c , Jack Klein
>> <jackklein@spam cop.net> wrote:
>>[/color][/color]
(of two files with int a; in them)
[color=blue][color=green][color=darkred]
>>>If you compile these two source files and combine them into a single
>>>executable , you produce undefined behavior.[/color]
>>
>> You sure? The second behaves exactly as if it had been declared
>> extern int a;[/color]
>
>Both have identical (external) linkage but their behaviour in terms of
>whether they create a definition is different.
>
>As such both a.c and b.c contain a definition of a so linking them
>produces undefined behaviour.[/color]

Really? The standard makes it pretty clear that in the absence of a
storage class specifier, a file-scope object is considered to be
extern. And FWIW I can't recall a compiler that behaves otherwise than
to consider two such declarations to be synonyms. I confess, my
initial thought was the same as yours, but closer reading of the
standard deconvinced me. Can you point me to the actual section that
confirms your view?


--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt >

----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

[Chris Torek]

Re: extern

>On Wed, 20 Jul 2005 13:39:13 +0100, in comp.lang.c , Lawrence Kirby[color=blue]
><lknews@netact ive.co.uk> wrote:[color=green]
>>... both a.c and b.c contain a definition of a so linking them
>>produces undefined behaviour.[/color][/color]

In article <hu90e1ho7cdo26 81mniuh1rkvckpn 6o02b@4ax.com>
Mark McIntyre <markmcintyre@s pamcop.net> wrote:[color=blue]
>Really? The standard makes it pretty clear that in the absence of a
>storage class specifier, a file-scope object is considered to be
>extern.[/color]

You are mixing up "linkage" -- which is indeed external -- with
"definition-ness". The extern keyword usually gives you external
linkage, and usually inhibits definitions. Without the keyword,
you still get external linkage, but the definition is not inhibited:

% grep var a.c b.c
a.c:int var;
b.c:extern int var;

Both have external linkage, but the "extern" in b.c inhibits
the definition, so that B.OBJ will contain a reference (in
compilers that use def/ref linkers).

Note that the "extern" keyword is pretty weak. If we modify b.c
to read, e.g.:

% grep var /dev/null b.c
b.c:static int var;
b.c:extern int var;

then the "var" in b.c has internal linkage (only), or if we modify
it to say "extern int var = 3;", it will be a definition (with
value 3), which will conflict with the definition (with value 0)
in A.OBJ using the system with the def/ref-model compiler. (Systems
that use "common model" and thus give the symbol "var" the type
"common block of size sizeof(int)" will see the Fortran COMMON
block -- this is where the name "common model" comes from -- in
a.o, and the data definition in b.o, and discard the COMMON-block
definition in favor of the data-definition, so again you will see
no conflict.)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[Netocrat]

Re: extern

Mark McIntyre wrote:[color=blue]
> On Wed, 20 Jul 2005 13:39:13 +0100, in comp.lang.c , Lawrence Kirby
> <lknews@netacti ve.co.uk> wrote:
>[color=green]
> >On Wed, 20 Jul 2005 12:03:08 +0100, Mark McIntyre wrote:
> >[color=darkred]
> >> On Tue, 19 Jul 2005 21:43:12 -0500, in comp.lang.c , Jack Klein
> >> <jackklein@spam cop.net> wrote:
> >>[/color][/color]
> (of two files with int a; in them)
>[color=green][color=darkred]
> >>>If you compile these two source files and combine them into a single
> >>>executable , you produce undefined behavior.
> >>
> >> You sure? The second behaves exactly as if it had been declared
> >> extern int a;[/color][/color][/color]

The same was my understanding until this thread, so perhaps I can
explain it knowing where you're coming from, because actually it
behaves as if it had been declared extern int a = 0;
[color=blue][color=green]
> >Both have identical (external) linkage but their behaviour in terms of
> >whether they create a definition is different.
> >
> >As such both a.c and b.c contain a definition of a so linking them
> >produces undefined behaviour.[/color]
>
> Really? The standard makes it pretty clear that in the absence of a
> storage class specifier, a file-scope object is considered to be
> extern.[/color]

You are probably referring to 6.2.2#5. As Chris Torek points out, this
section specifies that the extern keyword gives the object external
linkage. Aside from linkage, there are two other relevant contexts in
which the word "external" can be applied: to a declaration and to a
definition.
[color=blue]
> And FWIW I can't recall a compiler that behaves otherwise than
> to consider two such declarations to be synonyms. I confess, my
> initial thought was the same as yours, but closer reading of the
> standard deconvinced me. Can you point me to the actual section that
> confirms your view?[/color]

You seem to already know the part of the standard requiring that int a;
is treated as extern int a;

6.2.2#5
....
If the declaration of an identifier for
an object has file scope and no storage-class specifier, its
linkage is external.

Below an external declaration is defined as a file-scope declaration,
where it is also clarified that an initialiser turns a declaration into
a definition:

6.9#4
As discussed in 5.1.1.1, the unit of program text after
preprocessing is a translation unit, which consists of a
sequence of external declarations. These are described as
``external'' because they appear outside any function (and
hence have file scope). As discussed in 6.7, a declaration
that also causes storage to be reserved for an object or a
function named by the identifier is a definition.

Below we find out that int a; becomes int a = 0; by end of file in the
absence of other definitions. i.e. 6.2.2#5, 6.9#4 and 6.9.2#2 require
that our external declaration int a; by file end becomes the external
definition with external linkage: extern int a = 0.

6.9.2#2
[#2] A declaration of an identifier for an object that has
file scope without an initializer, and without a storage-
class specifier or with the storage-class specifier static,
constitutes a tentative definition. 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.

Below we find that a program shall only have one external definition
for each identifier that is actually used. Given that our two files
each contain an identical variable declaration that ultimately becomes
an external definition, this constraint is violated (unless the
variable is not actually used).

6.9#5
An external definition is an external declaration that
is also a definition of a function or an object. If an
identifier declared with external linkage is used in an
expression (other than as part of the operand of a sizeof
operator), somewhere in the entire program there shall be
exactly one external definition for the identifier;
otherwise, there shall be no more than one.127)
_______________ _____

127Thus, if an identifier declared with external linkage is
not used in an expression, there need be no external
definition for it.

Quite a chain of reasoning for the simple conclusion: we must use
extern for one of the declarations.

[Flash Gordon]

Re: extern

Mark McIntyre wrote:[color=blue]
> On Wed, 20 Jul 2005 13:39:13 +0100, in comp.lang.c , Lawrence Kirby
> <lknews@netacti ve.co.uk> wrote:
>
>[color=green]
>>On Wed, 20 Jul 2005 12:03:08 +0100, Mark McIntyre wrote:
>>
>>[color=darkred]
>>>On Tue, 19 Jul 2005 21:43:12 -0500, in comp.lang.c , Jack Klein
>>><jackklein@s pamcop.net> wrote:
>>>[/color][/color]
>
> (of two files with int a; in them)
>
>[color=green][color=darkred]
>>>>If you compile these two source files and combine them into a single
>>>>executabl e, you produce undefined behavior.
>>>
>>>You sure? The second behaves exactly as if it had been declared
>>>extern int a;[/color]
>>
>>Both have identical (external) linkage but their behaviour in terms of
>>whether they create a definition is different.
>>
>>As such both a.c and b.c contain a definition of a so linking them
>>produces undefined behaviour.[/color]
>
> Really?[/color]

Yes, really. See my reply to Old Wolf.
[color=blue]
> The standard makes it pretty clear that in the absence of a
> storage class specifier, a file-scope object is considered to be
> extern. And FWIW I can't recall a compiler that behaves otherwise than
> to consider two such declarations to be synonyms.[/color]

I can. gcc with the right option and MS VC 2003 when building a dll and
accessing it from a program. gcc with the correct option causes a linker
error, and IIRC MS VC creates something that does not work as expected.
[color=blue]
> I confess, my
> initial thought was the same as yours, but closer reading of the
> standard deconvinced me. Can you point me to the actual section that
> confirms your view?[/color]

See my reply to Old Wolf.
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.

[Flash Gordon]

Re: extern

Old Wolf wrote:[color=blue]
> Flash Gordon wrote:
>[color=green]
>>Mark McIntyre wrote:
>>[color=darkred]
>>>Sure - at file scope, an object with no storage class is by default
>>>extern.[/color]
>>
>>Wrong.
>>
>>A function declaration without "static" is extern by default, but that
>>is not true for objects. For objects it is a "tentative declaration" NOT
>> an extern, although it has external linkage (i.e. other translation
>>units can access it). If nothing else is seen by the end of the
>>translation unit then it is as if there was a declaration with a 0
>>initialiser at the end of the translation unit.[/color]
>
>
> Firstly, it is /tentative definition/, not declaration.[/color]

Your correct, I meant tentative definition.
[color=blue]
> Also, Mark McIntyre was taking about objects.[/color]

As am I mainly, I just mentioned that functions where different because
with a function declaration the extern keyword does not matter.
[color=blue]
> The tentative definition in question has external linkage.[/color]

Yes, which means that it can be accessed from another translation unit.
[color=blue]
> The object it identifies must also have external linkage --
> whether it is later explicitly declared or not.
>
> Mark McIntyre's comment seems correct; I don't understand the
> distinction you draw between an object being "an extern",
> vs. "having external linkage".[/color]

Possibly because the standard talks about linkage and the extern keyword
separately?

When talking about linkage, the defines three types of linkage, none,
internal and external.

None is irrelevant to our discussion since the standard say, "The
following identifiers have no linkage: an identifier declared to be
anything other than an object or a function; an identifier declared to
be a function parameter; a block scope identifier for an object declared
without the storage-class specifier extern."

Internal linkage is irrelevant since that is static objects, to quote,
"If the declaration of a file scope identifier for an object or a
function contains the storage class specifier static, the identifier has
internal linkage."

So obviously a variable either declared extern or defined at file scope
has external linkage. I.e. the linkage is external in the translation
unit that defines the storage and the translation units that only
reference it.

You have accepted that something like:
int i;
is a tentative definition when given at file scope. I also quoted that
at the end of the translation unit that becomes a an actual definition.

Annex A.2 Undefined behaviour, is only informative, not normative, but
it gives the clearest statement that having multiple definitions (which
having "int i;" at file scope in more than one translation unit gives
you) is undefined behaviour. It gives as one example of undefined behaviour:

"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 (6.9)."

Two definitions, whether the variable is used or not, falls fouls of
this rule.
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.

[Mark McIntyre]

Re: extern

On 22 Jul 2005 00:27:27 GMT, in comp.lang.c , Chris Torek
<nospam@torek.n et> wrote:

(as usual, a lucid explanation).

Thanks Chris and netocrat for the explanation.

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt >

----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

[Old Wolf]

Re: extern

Flash Gordon wrote:[color=blue]
> Old Wolf wrote:[color=green]
>> Flash Gordon wrote:
>>[color=darkred]
>>>Mark McIntyre wrote:
>>>
>>>>Sure - at file scope, an object with no storage class is by default
>>>>extern.
>>>
>>>Wrong.
>>>[/color]
>>
>> Mark McIntyre's comment seems correct; I don't understand the
>> distinction you draw between an object being "an extern",
>> vs. "having external linkage".[/color]
>
> Possibly because the standard talks about linkage and the extern keyword
> separately?[/color]

So you are using "an extern" to mean "something declared with
the keyword 'extern'". I (and Mark McIntyre, apparently), use
"an extern" to mean "something with external linkage".

[Flash Gordon]

Re: extern

Old Wolf wrote:[color=blue]
> Flash Gordon wrote:
>[color=green]
>>Old Wolf wrote:
>>[color=darkred]
>>>Flash Gordon wrote:
>>>
>>>>Mark McIntyre wrote:
>>>>
>>>>>Sure - at file scope, an object with no storage class is by default
>>>>>extern.
>>>>
>>>>Wrong.
>>>
>>>Mark McIntyre's comment seems correct; I don't understand the
>>>distinctio n you draw between an object being "an extern",
>>>vs. "having external linkage".[/color]
>>
>>Possibly because the standard talks about linkage and the extern keyword
>>separately?[/color]
>
> So you are using "an extern" to mean "something declared with
> the keyword 'extern'". I (and Mark McIntyre, apparently), use
> "an extern" to mean "something with external linkage".[/color]

Isn't life fun when people use terminology differently. In my mind, it
is important to know if something is defined in a module or merely
referenced, and in any case extern is a keyword with specific meaning,
so I use extern with the meaning it has when attached to a variable (or
function). This seems obvious to me. However, if to you it reads as
shorthand for external linkage, that's life. I don't see the point in
arguing about informal terminology. However, IIRC, the discussion was
started with an example showing something like, "int a;" *without*
extern in two files.
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.

[Netocrat]

Re: extern

On Mon, 25 Jul 2005 09:36:04 +0100, Flash Gordon wrote:
[color=blue]
> Old Wolf wrote:[color=green]
>> Flash Gordon wrote:[color=darkred]
>>>Old Wolf wrote:
>>>>Flash Gordon wrote:
>>>>>Mark McIntyre wrote:
>>>>>>Sure - at file scope, an object with no storage class is by default
>>>>>>extern.
>>>>>
>>>>>Wrong.
>>>>
>>>>Mark McIntyre's comment seems correct; I don't understand the
>>>>distincti on you draw between an object being "an extern",
>>>>vs. "having external linkage".
>>>
>>>Possibly because the standard talks about linkage and the extern keyword
>>>separately ?[/color][/color][/color]

6.2.2p4 fully defines the meaning of the extern keyword, and that is as
an external linkage declarator. An exception is made that where a
variable was previously declared with the static keyword, a later
declaration with the extern keyword does not reverse the original
internal linkage of the object, but clearly the general case is that
extern == external linkage.
[color=blue][color=green]
>> So you are using "an extern" to mean "something declared with the
>> keyword 'extern'". I (and Mark McIntyre, apparently), use "an extern"
>> to mean "something with external linkage".[/color][/color]

Which is exactly what it seems to be defined to be.
[color=blue]
> Isn't life fun when people use terminology differently. In my mind, it
> is important to know if something is defined in a module or merely
> referenced, and in any case extern is a keyword with specific meaning,
> so I use extern with the meaning it has when attached to a variable (or
> function).[/color]

And what meaning is that?

<snip>

[Richard Bos]

Re: extern

"Netocrat" <netocrat@dodo. com.au> wrote:
[color=blue]
> On Mon, 25 Jul 2005 09:36:04 +0100, Flash Gordon wrote:
>[color=green]
> > Old Wolf wrote:[color=darkred]
> >> Flash Gordon wrote:
> >>>Old Wolf wrote:
> >>>>Flash Gordon wrote:
> >>>>>Mark McIntyre wrote:
> >>>>>>Sure - at file scope, an object with no storage class is by default
> >>>>>>extern.
> >>>>>
> >>>>>Wrong.
> >>>>
> >>>>Mark McIntyre's comment seems correct; I don't understand the
> >>>>distincti on you draw between an object being "an extern",
> >>>>vs. "having external linkage".
> >>>
> >>>Possibly because the standard talks about linkage and the extern keyword
> >>>separately ?[/color][/color]
>
> 6.2.2p4 fully defines the meaning of the extern keyword, and that is as
> an external linkage declarator. An exception is made that where a
> variable was previously declared with the static keyword, a later
> declaration with the extern keyword does not reverse the original
> internal linkage of the object, but clearly the general case is that
> extern == external linkage.[/color]

No, it isn't. Declared extern usually implies external linkage, but not
v.v. Most objects and functions with external linkage are not declared
extern.
[color=blue][color=green][color=darkred]
> >> So you are using "an extern" to mean "something declared with the
> >> keyword 'extern'". I (and Mark McIntyre, apparently), use "an extern"
> >> to mean "something with external linkage".[/color][/color]
>
> Which is exactly what it seems to be defined to be.[/color]

Which of the two? With external linkage, or _explicitly_ declared with
external linkage? There's the whole point of this sub-thread, I think.

Richard

[Netocrat]

Re: extern

Richard Bos wrote:[color=blue]
> "Netocrat" <netocrat@dodo. com.au> wrote:[color=green]
> > On Mon, 25 Jul 2005 09:36:04 +0100, Flash Gordon wrote:[color=darkred]
> > > Old Wolf wrote:[/color][/color][/color]
<snip>[color=blue][color=green]
>> 6.2.2p4 fully defines the meaning of the extern keyword, and that is as
>> an external linkage declarator. An exception is made that where a
>> variable was previously declared with the static keyword, a later
>> declaration with the extern keyword does not reverse the original
>> internal linkage of the object, but clearly the general case is that
>> extern == external linkage.[/color]
>
> No, it isn't. Declared extern usually implies external linkage, but not
> v.v. Most objects and functions with external linkage are not declared
> extern.[/color]

"==" was the wrong thing to write, and not what I intended. Instead
substitute "means".
[color=blue][color=green][color=darkred]
> > >> So you are using "an extern" to mean "something declared with the
> > >> keyword 'extern'". I (and Mark McIntyre, apparently), use "an extern"
> > >> to mean "something with external linkage".[/color]
> >
> > Which is exactly what it seems to be defined to be.[/color]
>
> Which of the two? With external linkage, or _explicitly_ declared with
> external linkage? There's the whole point of this sub-thread, I think.[/color]

Right, again unclearly worded. I meant that "an extern" is defined as
"something with external linkage" (with the noted exception) but did
not intend to imply the reverse.

6.2.2 also specifies that for a function-scope variable declaration,
linkage is external regardless of whether the extern keyword is used or
ommitted (so long as static is not used).

[Netocrat]

Re: extern

On Mon, 25 Jul 2005 06:12:08 -0700, Netocrat wrote:
[color=blue]
> 6.2.2 also specifies that for a function-scope variable declaration,
> linkage is external regardless of whether the extern keyword is used or
> ommitted (so long as static is not used).[/color]

Ack, they just keep on rolling off my keyboard. Obviously I meant
file-scope, not function-scope.

[Joe Wright]

Re: extern

Richard Bos wrote:[color=blue]
> "Netocrat" <netocrat@dodo. com.au> wrote:
>
>[color=green]
>>On Mon, 25 Jul 2005 09:36:04 +0100, Flash Gordon wrote:
>>
>>[color=darkred]
>>>Old Wolf wrote:
>>>
>>>>Flash Gordon wrote:
>>>>
>>>>>Old Wolf wrote:
>>>>>
>>>>>>Flash Gordon wrote:
>>>>>>
>>>>>>>Mark McIntyre wrote:
>>>>>>>
>>>>>>>>Sure - at file scope, an object with no storage class is by default
>>>>>>>>exter n.
>>>>>>>
>>>>>>>Wrong.
>>>>>>
>>>>>>Mark McIntyre's comment seems correct; I don't understand the
>>>>>>distincti on you draw between an object being "an extern",
>>>>>>vs. "having external linkage".
>>>>>
>>>>>Possibly because the standard talks about linkage and the extern keyword
>>>>>separately ?[/color]
>>
>>6.2.2p4 fully defines the meaning of the extern keyword, and that is as
>>an external linkage declarator. An exception is made that where a
>>variable was previously declared with the static keyword, a later
>>declaration with the extern keyword does not reverse the original
>>internal linkage of the object, but clearly the general case is that
>>extern == external linkage.[/color]
>
>
> No, it isn't. Declared extern usually implies external linkage, but not
> v.v. Most objects and functions with external linkage are not declared
> extern.
>
>[color=green][color=darkred]
>>>>So you are using "an extern" to mean "something declared with the
>>>>keyword 'extern'". I (and Mark McIntyre, apparently), use "an extern"
>>>>to mean "something with external linkage".[/color]
>>
>>Which is exactly what it seems to be defined to be.[/color]
>
>
> Which of the two? With external linkage, or _explicitly_ declared with
> external linkage? There's the whole point of this sub-thread, I think.
>
> Richard[/color]

I didn't really choose this as response to Bos' post but as a place to
jump in. By default, functions and variables defined at file scope have
external linkage. This means that the compiler will provide a symbol
table or somesuch in the .o file in case than any other translation unit
might use the function or variable. This symbol table is information for
the linker so that it knows how to create an executable with information
from two or more .o files which would share information.

A second (or subsequent) translation unit that would call a function
from another can simply do so. The linker takes care of resolving this
call with the symbol table of the first translation unit.

In the general case, for a project with two or more translation units,
we can write a header, "proj.h", for inclusion in all translation units
which 'declare' for the compiler the myriad 'definitions' of functions
and variables among the translation units.

In the simple case, consider proj.h like..

int foo(int);
extern int bar;

Neither of these declarations makes a mark on the executable. They do
NOT create code. They are clues to the compiler. foo is a function. Call
it this way. bar is an int defined elsewhere (or here). It's yours.

In one and only one of the translation units we need a definition..

int foo(int i) {return i;}

...and in one and only one we need the definition at file scope..

int bar;

Now code in any of the translation units can could be..

bar = foo(1);

...with no confusion among the translation units about foo or bar.

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---