OK, so why _does_ ld resolve text against data?

[Karl Heuer]

In article <930 at eplunix.UUCP> das at eplunix.UUCP (David Steffens) writes:
>1> ... "lint" does identify the problem ...
>Only if the "problem" appears in _source code_ which can be linted.

Anything that isn't visible in lintable source code (e.g. a vendor's library)
ought to have a corresponding lint library already built.  (Not all do, but
then this is the vendor's bug.)

>int index;
>main() {
>	vendor_library_routine(); /* which, unknown to me, uses index() */
>}
>Even if the vendor provides a lint library, "lint" is no help at all!

Oh?  Let's try it.  (Quick switch to a BSD system...)
	$ cat bug.c
	int index;
	int main() { return 0; }
	$ lint bug.c
	bug.c:
	index value declared inconsistently     llib-lc(272)  ::  bug.c(1)
	$
Perhaps you mean systems on which `index' is not a documented interface, but
where a library happens to have a helper function with that name?  In that
case, the vendor is at fault for failing to declare it static.

>Is every programmer supposed to memorize the name of every libc routine just
>to avoid picking one by accident?

If you replace `every libc routine' with `every symbol reserved by the
standard to which the program attempts to conform', then I'd say Yes, it's a
good idea.  For those whose memory is less than perfect (or who don't have a
copy of the relevant standard), we have tools like lint.

>No sir.  In my view the linker is seriously deficient here.

I'll agree with the point that a type-checking linker would be a good thing.
It would probably slow down the linking pass, but I'd still use it if I had
it.

Karl W. Z. Heuer (karl at kelp.ima.isc.com or ima!kelp!karl), The Walking Lint
Followups to comp.lang.c only.