🚀 go-pugleaf

Guillaume Laurent <glaurent@nissart.lagaude.ibm.com> wrote:

>In article <4hdqjq$8pr@solutions.solon.com> fred@genesis.demon.co.uk (Lawrence Kirby) writes:

>> I mentioned object declarations above. Consider the following (assume
>> everything from here on is declared outside of any function):
>> 
>>     int i = 1;
>> 
>> The simplest case - this is a declaration that reserves space and hence
>> is also a definition. It has file scope i.e. is visible up until the end
>[...]
>>
>>     extern int i = 1;
>> 
>> This means exactly the same thing as int i = 1; The initialisation 'forces'
>> the definition (allocation of space).

>I've got a question here : what if the same above declaration is made
>in two (or more) files, compiled seperately then linked together ?

>ie, in file a.c :

>extern int i = 1;

>...

>and in file b.c :

>extern int i = 2;

>If I understand correctly what you've said, both of these declarations
>will reserve space, and give i a value. My question is, what decides
>which value will actually be "used", and what happens to the "duplicate"
>space ?

>>From what I've tried, the final effective value of i depends on the
>order of linking of the objects :

>cc a.o b.o -o foo  ---> i=1
>cc b.o a.o -o foo  ---> i=2

>But I'm still wondering about the "duplicate" space...

I don't know if the Standard has something to add to this, but K&R and
H&S both give <translation unit> as the topmost production in the C
syntax.  Therefore, what happens with "i" must be implementation
defined.  In practice, the linker will decide.  My linker gives an
error message, and quits [or so I thought. I've just tried, and it
creates an executable anyway: the second "i" is treated as if it had
been declared "static i;".  Funny, I had never tried to run a program
after getting linker errors before..]


==
Miguel Carrasquer Vidal                     ~ ~
Amsterdam                   _____________  ~ ~
mcv@pi.net                 |_____________|||

========================== Ce .sig n'est pas une .cig