Xref: utzoo comp.unix.wizards:23566 comp.lang.c:31291
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!husc6!spdcc!eplunix!das
From: das@eplunix.UUCP (David Steffens)
Newsgroups: comp.unix.wizards,comp.lang.c
Subject: OK, so why _does_ ld resolve text against data?
Message-ID: <930@eplunix.UUCP>
Date: 17 Aug 90 19:45:38 GMT
References: <1990Jul30.104726.22660@mtcchi.uucp> <37909@ucbvax.BERKELEY.EDU>
Organization: Eaton-Peabody Lab, Boston, MA
Lines: 64

Apologies if you've seen this before.  Posted the original on 6 Aug.
Haven't seen any disscussion since, although I was expecting some.
Posting a revised version again with a shortened subject line
on the assumption that the original article didn't make it offsite.
----------
In article <1990Jul30.104726.22660@mtcchi.uucp>
levy@mtcchi.UUCP (Daniel R. Levy) writes:

1> Now my question is, why does the linker silently resolve
1> [ a ] function reference to [ a ] global variable
1> without even a whisper of a warning? ...
1> Yes I know [ using the same name for a function and global variable ]
1> is a stupid thing to do ... 

But there are cases where this can occur unintentionally.
Not all of these cases are immediately obvious to the programmer,
and some of them are not "stupid", at least by my definition of the word.

1> ... "lint" does identify the problem ...

Only if the "problem" appears in _source code_ which can be linted.

In article: <37909@ucbvax.BERKELEY.EDU>
edward@ucbarpa.Berkeley.EDU.UUCP (Edward Wang) writes:

2> The only impact this has on the language is that global
2> variables and functions must share the same name space.

Said shared name space extends beyond the confines of _my_ code, however.
And that makes it a linker problem, _not_ a compiler problem.

2> Your program has a C error, no different from declaring
2> a variable as an int in one place and as a float somewhere else.
2> True, the compiler should catch it, but the current organization
2> makes it difficult.  (Use lint.)
2> ...
2> Anyway, it's not the linker's fault.  It's the compiler's fault.

Yes, the original program has a C error, and yes, lint will catch that one.
Nevertheless, the linker _is_ blameworthy because it will _also_ happily
use the address of one of my global variables to resolve a function call
embedded in a library routine for which I have no lintable source, e.g.

int index;
main()
{
	/* lots of code, none of which uses index() */
	vendor_library_routine(); /* which, unknown to me, uses index() */
}

Even if the vendor provides a lint library, "lint" is no help at all!

This actually happened to one of our programmers (a good one, IMHO).
Should I call her "stupid" just because she doesn't know that "index"
is a _dirty name_ and might be used by some vendor in writing his library?
The chances of a name collision of this sort rises exponentially
with every new UNIX release.  Is every programmer supposed to memorize
the name of every libc routine just to avoid picking one by accident?
No sir.  In my view the linker is seriously deficient here.
-- 
David Allan Steffens       | I believe in learning from past mistakes...
Eaton-Peabody Laboratory   | ...but does a good education require so many?
Mass. Eye & Ear Infirmary, 243 Charles Street, Boston, MA 02114
{harvard,mit-eddie,think}!eplunix!das      (617) 573-3748 (1400-1900h EST)