OK, so why _does_ ld resolve text against data?

[Edward Wang]

Our difference is mostly one of semantics.  I say compiler, you say linker;
I say tom-ay-to, you say tom-ah-to.  However, there is a point to make here.

You said:
>. . .
>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() */
>}
>. . .
>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?
>. . .

Why stop there, why not redefine index() while you're at it?
Defining index to be a variable is easy to debug.  It'll most likely
core dump on the call.  Unintentionally redefining index to be a function
of exactly the same type, arguments and all, is uncatchable and much harder
to debug.  The compiler-linker combination can at best give a warning,
and I'm against that because it gets in the way of correct programs.

It's all part of the same ball of wax of uncaught-by-the-compiler C errors.
Why are we complaining about the easy ones?

[I also wrote a much longer, and somewhat more serious, reply to the
the poster (lost his name).  Those who get off on this stuff can
ask for that.]