Re: How a linker works (continued)



jacob navia <jacob@xxxxxxxxxx> writes:
<snip>
This can be tested, for instance, with the following two files:
file t1.c
int tab[12];

File t2.c
int tab[256];
int main(void){return 0;}

Linking t1.c and t2.c with MSVC 8 we obtain an executable *without any
warnings* not even at the highest warning level.

In the linker of lcc-win I added a warning:
in t1.obj warning: '_tab' (defined with size 48)
is redefined in t2.obj with size 1024

The linker of gnu doesn't emit any warning:
root@ubuntu:/tmp# gcc -Wall t1.c t2.c

*Please* post these articles in comp.programming. I'd join in a lot
more if I could do so and be topical. However, you are dead set on
knocking gcc without understanding it so...

<off-topic>
gcc uses the GNU linker ld. ld merges the common blocks to make tab
the larger of the two size regardless of the linking order. In this
case, I can't see why you'd want a diagnostic[1]. When a compilation
unit initialises the table (so it can't be merged) the GNU linker
*does* produce a warning:

/usr/bin/ld: Warning: size of symbol `tab' changed from 1024 in t1.o
to 16 in t2.o
</off-topic>

<snip>
Next installment will treat the object libraries

Please post it where it belongs.

[1] OK, a case can be made for a diagnostic in all such cases, but you
are suggesting the gcc leads the programmer silently into a trap.

--
Ben.
.