Xref: utzoo comp.unix.wizards:23637 comp.lang.c:31385
Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!mcnc!rti!sheol!throopw
From: throopw@sheol.UUCP (Wayne Throop)
Newsgroups: comp.unix.wizards,comp.lang.c
Subject: Re: OK, so why _does_ ld resolve text against data?
Summary: I still don't see any reason why it shouldn't
Message-ID: <0879@sheol.UUCP>
Date: 26 Aug 90 19:06:13 GMT
References: <930@eplunix.UUCP>
Lines: 24

> From: das@eplunix.UUCP (David Steffens)
> Said shared name space extends beyond the confines of _my_ code, however.
> And that makes it a linker problem, _not_ a compiler problem.

I disagree most strenuously.  The compiler is the agent that "decided"
to name things that should definitely not be resolved together with
the same name.  The linker advertises what it will do with its namespace,
and the compiler decides to name two incompatible things with the
same linker name.  I think it quite clear that the compiler is at fault.

One may object that the compiler is merely naming the entity with the
name given it in the source code.  But this just isn't (normally) so,
even (or maybe especially) in C.  In fact, it is common to play games
with the link-time names of things.  Fortran, for example, twiddles with
case, C prepends a superfluous "_".  And more recent C++ implementations
choose names which reflect the type of the link-time object generated. 

So, if the compiler would simply tag things with link-time names which
reflect the distinctions that should be made, the link will do the right
thing, and can even produce intelligible source-level error messages
if it is made privy to some backtranslation database.
--
Wayne Throop <backbone>!mcnc!rti!sheol!throopw or sheol!throopw@rti.rti.org