By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,617 Members | 1,792 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,617 IT Pros & Developers. It's quick & easy.

"extern" meaning

P: n/a
Hi all,
I am reading "C: A Reference Manual" 4th ed and I get lost for the
"extern". It says that global object without specifying the
storage-class specifier will have "extern" as the default storage-class
specifier. My (little) C experience tells me that an object with
"extern" is to let the linker knows that the object is referencing the
object defined in somewhere, and this "somewhere" object does not have
the storage-class specifier "extern". That is:
<------------ file A ------------>
int A;
...
A=10;
<------------ file B ------------>
extern int A;
if (A)
...

But if the default storage-class specifier is "extern", then
variable "int A" is, indeed, "extern int A". Then who is the definiting
occurence?
Please correct me if there is a mis-concept.

Nov 14 '05 #1
Share this Question
Share on Google+
19 Replies


P: n/a
ccwork wrote:
Hi all,
I am reading "C: A Reference Manual" 4th ed and I get lost for the
"extern". It says that global object without specifying the
storage-class specifier will have "extern" as the default storage-class specifier. My (little) C experience tells me that an object with
"extern" is to let the linker knows that the object is referencing the object defined in somewhere, and this "somewhere" object does not have the storage-class specifier "extern". That is:
<------------ file A ------------>
int A;
...
A=10;
<------------ file B ------------>
extern int A;
if (A)
...

But if the default storage-class specifier is "extern", then
variable "int A" is, indeed, "extern int A". Then who is the definiting occurence?
Please correct me if there is a mis-concept.


'extern' specifies external linkage for an identifier, nothing more.
It makes the identifier known to the linker so it could be referenced.

The definition of variable A occurs in file "A".

P.Krumins

Nov 14 '05 #2

P: n/a
ccwork wrote:
I am reading "C: A Reference Manual" 4th ed and I get lost for the
"extern". It says that global object without specifying the
storage-class specifier will have "extern" as the default storage-class
specifier. My (little) C experience tells me that an object with
"extern" is to let the linker knows that the object is referencing the
object defined in somewhere, and this "somewhere" object does not have
the storage-class specifier "extern". That is:
<------------ file A ------------>
int A;
...
A=10;
<------------ file B ------------>
extern int A;
if (A)
...

But if the default storage-class specifier is "extern", then
variable "int A" is, indeed, "extern int A". Then who is the definiting
occurence?
Please correct me if there is a mis-concept.


C language doesn't not rely on the concept of "linker". There's no
"linker" in C. At language level, external linkage of an identifier
means just one thing - that this identifier refers to the same object
(or function) in all translation units. How this requirement is
implemented in practice (using that "linker" thingy or something else)
is an implementation detail, a completely different story, irrelevant to
the language itself.

If you really want to think about this in terms of "exporting/importing"
access to the object, think of it this way: when 'extern' is included in
a _definition_ of some object, it "exports" the corresponding identifier
to the outside world (i.e. other translation units), but when 'extern'
is included in a mere _declaration_ of an object, it "imports" the
identifier from the outside world.

In your case 'int A' in file 'A' is a definition of an identifier 'A'
attached to an object of type 'int'. This identifier has external
linkage by default, meaning that identifier 'A' is "exported", made
accessible from other translation units. In order to access this object
other translation units have to "import" this identifier by providing an
'extern' _declaration_ for it. That's exactly what you have in file 'B'.

--
Best regards,
Andrey Tarasevich
Nov 14 '05 #3

P: n/a
Andrey Tarasevich wrote:

C language doesn't not rely on the concept of "linker".
[I presume you didn't mean to add the extra 'not'.]
There's no "linker" in C.
So what's translation phase 8 all about then?
At language level, external linkage of an identifier means just
one thing - that this identifier refers to the same object (or
function) in all translation units. How this requirement is
implemented in practice (using that "linker" thingy or something
else) is an implementation detail, a completely different story,
irrelevant to the language itself.


"Library components are linked..."

How does an implementation link _without_ a linker?

Even C interpreters must have a linker, just as they must have
a function call stack.

--
Peter

Nov 14 '05 #4

P: n/a

Andrey Tarasevich wrote:
ccwork wrote:
I am reading "C: A Reference Manual" 4th ed and I get lost for the "extern". It says that global object without specifying the
storage-class specifier will have "extern" as the default storage-class specifier. My (little) C experience tells me that an object with
"extern" is to let the linker knows that the object is referencing the object defined in somewhere, and this "somewhere" object does not have the storage-class specifier "extern". That is:
<------------ file A ------------>
int A;
...
A=10;
<------------ file B ------------>
extern int A;
if (A)
...

But if the default storage-class specifier is "extern", then
variable "int A" is, indeed, "extern int A". Then who is the definiting occurence?
Please correct me if there is a mis-concept.
C language doesn't not rely on the concept of "linker". There's no
"linker" in C. At language level, external linkage of an identifier
means just one thing - that this identifier refers to the same object
(or function) in all translation units. How this requirement is
implemented in practice (using that "linker" thingy or something

else) is an implementation detail, a completely different story, irrelevant to the language itself.

If you really want to think about this in terms of "exporting/importing" access to the object, think of it this way: when 'extern' is included in a _definition_ of some object, it "exports" the corresponding identifier to the outside world (i.e. other translation units), but when 'extern' is included in a mere _declaration_ of an object, it "imports" the
identifier from the outside world.

In your case 'int A' in file 'A' is a definition of an identifier 'A'
attached to an object of type 'int'. This identifier has external
linkage by default, meaning that identifier 'A' is "exported", made
accessible from other translation units. In order to access this object other translation units have to "import" this identifier by providing an 'extern' _declaration_ for it. That's exactly what you have in file

'B'.

That's the problem. Since global variable is regraded as "extern"
(is this right?), in other words, file A means:
<------------ file A ------------>
extern int A;
...
A=10;
<------------ file B ------------>
extern int A;
if (A)
...

Then how do I know which one is the defining occurrence of A? Does
the assignment on A=10 specify the declaraction "extern int A" in file
A is the definition? Or else?

Nov 14 '05 #5

P: n/a


if both files have variabled defined as "extern" , there is no harm if
one is of the form:

extern int a =1;

i will try on rh9 to test it.

Nov 14 '05 #6

P: n/a
ccwork wrote:
...
In your case 'int A' in file 'A' is a definition of an identifier 'A'
attached to an object of type 'int'. This identifier has external
linkage by default, meaning that identifier 'A' is "exported", made
accessible from other translation units. In order to access this object
other translation units have to "import" this identifier by providing

an
'extern' _declaration_ for it. That's exactly what you have in file

'B'.

That's the problem. Since global variable is regraded as "extern"
(is this right?), in other words, file A means:
<------------ file A ------------>
extern int A;
...
A=10;
<------------ file B ------------>
extern int A;
if (A)
...


No. The original 'int A' was a _definition_ of an object with external
linkage. 'extern int A' is a non-defining _declaration_ of an identifier
with external linkage. These are not the same.

'int A' defines an object with external linkage, but that doesn't mean
that you can just add an explicit 'extern' keyword here and get the same
thing. Adding 'extern' to 'int A' will have an unwanted side effect of
turning this definition into a non-defining declaration.
Then how do I know which one is the defining occurrence of A?
Neither. 'A' is not defined in the above files.
Does
the assignment on A=10 specify the declaraction "extern int A" in file
A is the definition?


Assignment? How do intend to use assignment here?

If you include an initializer into the declaration, this declaration
will become a definition, even if you specify an explicit 'extern'

extern int A; // non-defining declaration
extern int A = 0; // definition

--
Best regards,
Andrey Tarasevich

Nov 14 '05 #7

P: n/a
ccwork wrote:
Andrey Tarasevich wrote:
ccwork wrote:
I am reading "C: A Reference Manual" 4th ed and I get lost for
the
"extern". It says that global object without specifying the
storage-class specifier will have "extern" as the default
storage-class
specifier. My (little) C experience tells me that an object with
"extern" is to let the linker knows that the object is referencing
the
object defined in somewhere, and this "somewhere" object does not
have
the storage-class specifier "extern". That is:
<------------ file A ------------>
int A;
...
A=10;
<------------ file B ------------>
extern int A;
if (A)
...

But if the default storage-class specifier is "extern", then
variable "int A" is, indeed, "extern int A". Then who is the
definiting
occurence?
Please correct me if there is a mis-concept.


C language doesn't not rely on the concept of "linker". There's no
"linker" in C. At language level, external linkage of an identifier
means just one thing - that this identifier refers to the same object
(or function) in all translation units. How this requirement is
implemented in practice (using that "linker" thingy or something


else)
is an implementation detail, a completely different story, irrelevant


to
the language itself.

If you really want to think about this in terms of


"exporting/importing"
access to the object, think of it this way: when 'extern' is included


in
a _definition_ of some object, it "exports" the corresponding


identifier
to the outside world (i.e. other translation units), but when


'extern'
is included in a mere _declaration_ of an object, it "imports" the
identifier from the outside world.

In your case 'int A' in file 'A' is a definition of an identifier 'A'
attached to an object of type 'int'. This identifier has external
linkage by default, meaning that identifier 'A' is "exported", made
accessible from other translation units. In order to access this


object
other translation units have to "import" this identifier by providing


an
'extern' _declaration_ for it. That's exactly what you have in file


'B'.

That's the problem. Since global variable is regraded as "extern"
(is this right?), in other words, file A means:
<------------ file A ------------>
extern int A;
...
A=10;
<------------ file B ------------>
extern int A;
if (A)
...

Then how do I know which one is the defining occurrence of A? Does
the assignment on A=10 specify the declaraction "extern int A" in file
A is the definition? Or else?


'extern' indicates to the compiler the actual storage space is allocated
elsewhere. Because now your example (is slightly different to above) has
no 'int A', only 'extern int A', no storage space is actually created for A.

Hence at link time there will be a failure as A is not defined anywhere.

As for A=10, that doesn't actually allocate space, this is just an
assignment, it has nothing to do with the definition of A.
Nov 14 '05 #8

P: n/a
On Tue, 05 Apr 2005 18:06:28 -0700, ccwork wrote:
Hi all,
I am reading "C: A Reference Manual" 4th ed and I get lost for the
"extern". It says that global object without specifying the
storage-class specifier will have "extern" as the default storage-class
specifier.
C doesn't define the term "global". It is commonly used and misused in
different and contradictory ways. I assume the text above is referring to
declarations at file scope i.e. outside of any function.
My (little) C experience tells me that an object with
"extern" is to let the linker knows that the object is referencing the
object defined in somewhere, and this "somewhere" object does not have
the storage-class specifier "extern". That is:
<------------ file A ------------>
int A;
...
A=10;
<------------ file B ------------>
extern int A;
if (A)
...

But if the default storage-class specifier is "extern", then
variable "int A" is, indeed, "extern int A". Then who is the definiting
occurence?


It is incorrect to say that the default storage-class specifier is extern,
however it would be correct to say that the default linkage for file scope
declarations is external. The presence of extern in file B above makes a
difference, extern int A is just a declaration, it doesn't act as a
definition of A. int A; does (technically it is called a tentative
definition but the end resukt is that it is a definition here). Note that
providing an initialiser forces it to be a full definition, e.g.

extern int A = 1; /* Is a full definition */

Lawrence
Nov 14 '05 #9

P: n/a
On 5 Apr 2005 21:18:19 -0700, in comp.lang.c , "Peter Nilsson"
<ai***@acay.com.au> wrote:
How does an implementation link _without_ a linker?
who knows - maybe it does runtime binding, like, er most OSen do...
Even C interpreters must have a linker, just as they must have
a function call stack


Must they? Does it say that in the standard? .

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

P: n/a
Jason Curl wrote:
'extern' indicates to the compiler the actual storage space is allocated
elsewhere.


Not necessarily:
extern int a = 10;
This is a valid definition with external linkage.
Christian
Nov 14 '05 #11

P: n/a
On Wed, 06 Apr 2005 16:29:18 +0200, in comp.lang.c , Christian
Kandeler <ch****************@hob.de_invalid> wrote:
Jason Curl wrote:
'extern' indicates to the compiler the actual storage space is allocated
elsewhere.


Not necessarily:
extern int a = 10;
This is a valid definition with external linkage.


Well yes, but this isn't relevant to Jason's point. All identifiers
at file scope have external linkage unless specified as static.

The extern tells the compiler to look elsewhere for a definition.
However if an initialisation is supplied, the storage class specifier
is ignored.

--
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 =----
Nov 14 '05 #12

P: n/a
Mark McIntyre wrote:
...
'extern' indicates to the compiler the actual storage space is allocated
elsewhere.


Not necessarily:
extern int a = 10;
This is a valid definition with external linkage.


Well yes, but this isn't relevant to Jason's point. All identifiers
at file scope have external linkage unless specified as static.

The extern tells the compiler to look elsewhere for a definition.
However if an initialisation is supplied, the storage class specifier
is ignored.
...


While this description might be accurate enough for practical purposes,
it still does not match the approach to "external linkage" used in the
language specification.

'extern' specifier explicitly describes an identifier as having external
linkage. This is as true in cases when 'extern' is a part of a
non-defining declaration, as it is true in cases when 'extern' is a part
of a definition. When applied to a declaration, it indeed means that the
compiler has to look for a definition elsewhere. When applied to a
definition, its meaning is essentially reversed: it means that this
definition can be looked up from some other place.

--
Best regards,
Andrey Tarasevich
Nov 14 '05 #13

P: n/a
On Wed, 06 Apr 2005 13:38:54 -0700, in comp.lang.c , Andrey Tarasevich
<an**************@hotmail.com> wrote:
Mark McIntyre wrote:
...
'extern' indicates to the compiler the actual storage space is allocated
elsewhere.

Not necessarily:
extern int a = 10;
This is a valid definition with external linkage.
Well yes, but this isn't relevant to Jason's point. All identifiers
at file scope have external linkage unless specified as static.

The extern tells the compiler to look elsewhere for a definition.
However if an initialisation is supplied, the storage class specifier
is ignored.
...


While this description might be accurate enough for practical purposes,
it still does not match the approach to "external linkage" used in the
language specification.


I actually think it does.
'extern' specifier explicitly describes an identifier as having external
linkage.
Yes. But then at file scope, only objects with static storage-class
specifier have any other sort of linkage (6.2.2p5)
When applied to a
definition, its meaning is essentially reversed: it means that this
definition can be looked up from some other place.


This is true for /any/ non-static file-scope variable, by definition.
The storage-class specifier has no effect.

--
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 =----
Nov 14 '05 #14

P: n/a
>Mark McIntyre wrote:
Well yes, but this isn't relevant to Jason's point. All identifiers
at file scope have external linkage unless specified as static.
(There is an exception to this rule; see below.)
The extern tells the compiler to look elsewhere for a definition.
However if an initialisation is supplied, the storage class specifier
is ignored.

In article <11*************@news.supernews.com>
Andrey Tarasevich <an**************@hotmail.com> wrote:While this description might be accurate enough for practical purposes,
it still does not match the approach to "external linkage" used in the
language specification.
Yes. But the real problem here is confusion between the keyword
"extern", which is syntactically a storage-class specifier (in the
same group as "static", "register", and "typedef"), and "external
linkage", which has almost nothing to do with the keyword. In C's
tradition of misusing the English language, :-) the word "extern"
is not required to mean "external linkage", so it does not. The
"const" keyword does not define constants, "typedef" does not define
new types, and "extern" does not mean external linkage. (Similarly,
"static" sometimes means "static storage" and sometimes means
something else entirely, as will appear below.)
'extern' specifier explicitly describes an identifier as having external
linkage. This is as true in cases when 'extern' is a part of a
non-defining declaration, as it is true in cases when 'extern' is a part
of a definition. When applied to a declaration, it indeed means that the
compiler has to look for a definition elsewhere. When applied to a
definition, its meaning is essentially reversed: it means that this
definition can be looked up from some other place.


I am not sure what you mean to say with that last sentence. I think
the only way to fully describe the "extern" keyword is to exhaustively
enumerate all the ways in which it can be used with a variable-name.
These are:

/* all outside a function */
int a; /* not extern */
extern int b;

int d = 0;
extern int e = 0;

static int g;
extern int g;
int g;
int g = 42;

void func(void) {
extern int h;
int i;
static int j;
}

Here "a" is both declared and defined, because we omitted the
extern keyword. We have no initializer so this is a "tentative
definition" -- we can later write "int a = 3" to set a to 3
instead of the default 0, but by the end of the translation
unit, the variable will be defined.

The variable "b", on the other hand, is only declared. The
extern keyword suppresses the tentative definition. This is
its only real function when applied to file-scope variables:
it only ever suppresses definitions, and only when they would
have been tentative anyway (as we will see with "e").

Next we have d and e, which are declared-and-defined and both
explicitly initialized. These are not tentative definitions
so the "extern" keyword has no effect -- it can only suppress
tentative definitions.

Now we have g. This is one of the more peculiar cases. By first
declaring it "static", and not using an initializer, we create a
tentative definition and inhibit the default linkage (external
linkage) -- we wind up with a file-scope g with internal linkage,
which will be initialized to 0 if we do not override this. The
second declaration uses the "extern" keyword. In this case, the
keyword *also* means "static", because we already have a definition
of the same identifier at the same scope. When the identifier is
already defined, "extern" means "whatever linkage it had before".
The third declaration for "g" *also* means "static": the absence
of the "extern" keyword fails to suppress tentative-definition-ness,
but has no effect on linkage, because the default linkage behavior
is to act as if the "extern" keyword had been present. Finally,
the fourth line for "g" is a real, solid, actual definition -- not
tentative -- and gives it the value 4. As before, the nonexistent
extern keyword has no effect on linkage: the linkage is the same
as if we had used the extern keyword, and is still "static". All
four declarations mean the same thing, but only the fourth is
a non-tentative definition.

The "extern" keyword does sometimes means something more than
"suppress tentative definition", though, and this appears inside
the function func(). The variable h is declared (but not
defined) as having external linkage. Its scope is limited;
the declaration disappears after the "}" that ends the function.
The variable i is both declared and defined, and has automatic
storage duration; and the variable j is also both declared and
defined, and has static storage duration.

Note that all file-scope variables always have static duration:
a, b, d, e, and g are all static-duration variables. Like the
"extern" keyword, the "static" keyword would be redundant; so, like
the "extern" keyword, the "static" keyword is given a new and
unrelated meaning: it alters the identifier's linkage. The
"non-static" variables (a, b, d, and e) have external linkage, but
the "static" variable (g) has internal linkage.

We can now summarize this:

extern:
If a variable would have had no linkage (and thus automatic
storage duration), this keyword gives it linkage, usually
external, but sometimes internal. If the variable would
already have had external or internal linkage, the "extern"
keyword has no effect on linkage; instead, it suppresses
tentative definitions, but not actual definitions.

static:
If a variable would have had automatic storage duration
(and thus no linkage), this keyword gives it static storage
duration instead. Otherwise, it gives the variable internal
linkage.

These two keywords can also be applied to function-names, but since
functions never have storage duration to worry about, the situation
there is simpler: "extern" has no effect, and "static" only affects
linkage.

There is one situation I deliberately glossed over. It is possible
to give the same identifier both internal and external linkage in
the same translation unit. We do this by hiding the internal-linkage
name with a function-scope name, then using the "extern" keyword:

static int x; /* internal linkage, file scope, static duration */

void f(void) {
int x; /* hides the internal-linkage x */
{
extern int x; /* BAD - DO NOT DO THIS */
}
}

The C Standards (C89 and C99 both) say that the behavior here is
undefined. We simply do not know what will happen -- will we
get this translation unit's x, or some other translation unit's
x, or will things just go kaboom? It is probably wisest not to
find out the hard way. :-)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (4039.22'N, 11150.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.
Nov 14 '05 #15

P: n/a
Mark McIntyre wrote:
"Peter Nilsson" <ai***@acay.com.au> wrote:
How does an implementation link _without_ a linker?


who knows - maybe it does runtime binding, like, er most OSen
do...


Then that's the linker, or part of it.
Even C interpreters must have a linker, just as they must have
a function call stack


Must they? Does it say that in the standard? .


Yes. My quote, which you snipped, was from the the standard.

To remind you, it's translation phase 8.

--
Peter

Nov 14 '05 #16

P: n/a
Chris Torek wrote:
static int g;
extern int g;
int g;
int g = 42;
[ ... ]
Now we have g. This is one of the more peculiar cases. By first
declaring it "static", and not using an initializer, we create a
tentative definition and inhibit the default linkage (external
linkage) -- we wind up with a file-scope g with internal linkage,
which will be initialized to 0 if we do not override this. The
second declaration uses the "extern" keyword. In this case, the
keyword *also* means "static", because we already have a definition
of the same identifier at the same scope. When the identifier is
already defined, "extern" means "whatever linkage it had before".
Yes, according to 6.2.2 [#4] in N869.
The third declaration for "g" *also* means "static": the absence
of the "extern" keyword fails to suppress tentative-definition-ness,
but has no effect on linkage, because the default linkage behavior
is to act as if the "extern" keyword had been present. Finally,
the fourth line for "g" is a real, solid, actual definition -- not
tentative -- and gives it the value 4. As before, the nonexistent
extern keyword has no effect on linkage: the linkage is the same
as if we had used the extern keyword, and is still "static". All
four declarations mean the same thing, but only the fourth is
a non-tentative definition.


I believe this is one of the rare occasions on which you are mistaken. In my
opinion, lines three and four are illegal in combination with line one.
According to the Standard: "If, within a translation unit, the same
identifier appears with both internal and external linkage, the behavior is
undefined". The "extern" keyword has to be present to suppress that, as in
line two. An example in 6.9.2 directly supports this claim:
static int i5; // tentative definition, internal linkage
int i5; // 6.2.2 renders undefined, linkage disagreement
Also (and I know this not a proof, but still):
$ cat > test.c
$ static int g;
$ extern int g;
$ int g;
$ int g = 42;
$ gcc -c -W -Wall -ansi -pedantic -c test.c
$ test.c:3: error: conflicting declarations of `g'
$ test.c:2: error: `g' previously declared here
$ test.c:2: warning: `g' defined but not used
Christian
Nov 14 '05 #17

P: n/a
>Chris Torek wrote:
static int g;
extern int g;
int g;
int g = 42; ... The third declaration for "g" *also* means "static" ...

In article <42***********************@news.sunsite.dk>
Christian Kandeler <ch****************@hob.de_invalid> wrote:I believe this is one of the rare occasions on which you are mistaken. In my
opinion, lines three and four are illegal in combination with line one.
Oops, you are right. My C99 draft has slightly different section
numbers, but when declaring objects (not functions), the lack of
the "extern" keyword forces external linkage.
... An example in 6.9.2 directly supports this claim:
static int i5; // tentative definition, internal linkage
int i5; // 6.2.2 renders undefined, linkage disagreement


The Standard's example agrees with its wording (always a good thing :-) ).

It seems a bit odd to apply different rules to functions and objects
here -- and there is no fundamental reason not to do the same
"backwards search for previous linkage information" that happens
with "extern int g" -- but that is what the Standard says, so we
must live with it.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (4039.22'N, 11150.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.
Nov 14 '05 #18

P: n/a
On 6 Apr 2005 21:51:16 -0700, in comp.lang.c , "Peter Nilsson"
<ai***@acay.com.au> wrote:
Mark McIntyre wrote:
"Peter Nilsson" <ai***@acay.com.au> wrote:
> How does an implementation link _without_ a linker?


who knows - maybe it does runtime binding, like, er most OSen
do...


Then that's the linker, or part of it.


*shrug*. I don't call it a linker, you can if you want.
> Even C interpreters must have a linker, just as they must have
> a function call stack


Must they? Does it say that in the standard? .


To remind you, it's translation phase 8.


..... and where does that say that a linker must exist, or that a
function call stack must exist?

It says "Library components are linked to satistify external
references...". This doesn't require a linker, any more than linking
hands or daisies or creating a linked list requires a linker. Linking
is not only done with linkers, if you see what I mean.

Sure, I'm being pedantic. The point is, the standard doesn't require
the existence of some software called "a linker", it merely requires
that external references be resolved in such a way that a program
image can be formed suitable for execution in the relevant
environment.

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

P: n/a
On 6 Apr 2005 21:51:16 -0700, in comp.lang.c , "Peter Nilsson"
<ai***@acay.com.au> wrote:
Mark McIntyre wrote:
"Peter Nilsson" <ai***@acay.com.au> wrote:
> How does an implementation link _without_ a linker?


who knows - maybe it does runtime binding, like, er most OSen
do...


Then that's the linker, or part of it.


*shrug*. I don't call it a linker, you can if you want.
> Even C interpreters must have a linker, just as they must have
> a function call stack


Must they? Does it say that in the standard? .


To remind you, it's translation phase 8.


..... and where does that say that a linker must exist, or that a
function call stack must exist?

It says "Library components are linked to satistify external
references...". This doesn't require a linker, any more than linking
hands or daisies or creating a linked list requires a linker. Linking
is not only done with linkers, if you see what I mean.

Sure, I'm being pedantic. The point is, the standard doesn't require
the existence of some software called "a linker", it merely requires
that external references be resolved in such a way that a program
image can be formed suitable for execution in the relevant
environment.

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

This discussion thread is closed

Replies have been disabled for this discussion.