Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!zaphod.mps.ohio-state.edu!wuarchive!udel!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.lang.c
Subject: Re: OK, so why _does_ ld resolve text against data?
Message-ID: <13657@smoke.BRL.MIL>
Date: 23 Aug 90 20:09:20 GMT
References: <37909@ucbvax.BERKELEY.EDU> <930@eplunix.UUCP> <3605@goanna.cs.rmit.oz.au>
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Lines: 25

In article <3605@goanna.cs.rmit.oz.au> ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes:
>The UNIX linkers allow a function reference to be resolved by a global
>variable because they have no way at all of telling one from another.
>The title of this thread refers to "text" and "data", but a read-only
>array may well be in "text" space.  Consider the "-R" flag on BSD UNIX
>compilers and the "const" keyword in ANSI C.

There are UNIX linkers that maintain sufficient object module segment
attributes that they are able to detect such abuse.  However, the linker
shipped with 4.nBSD is not one of these.  The simpler linkage scheme has
both good and bad points, depending on what your detailed needs are.
It is not clear to me that you should rely on a linker to help you debug
faulty code or poor system library implementations, though.  

>Myself, I don't see data/function collisions as being any worse than
>function/function collisions.

Right.  The more general issue is how to control allocation of the
external ("global") name space.  There is no fully satisfactory method,
but through means such as object-oriented interfaces the collisions can
be drastically reduced, and one can control one's OWN code by setting up
a "package prefix" scheme such as I have previously described.  There's
not much to be done about multiple third-party provided libraries that
conflict in the use of external identifiers such as "get" and "put",
other than of course to not purchase them (and to let the vendor know why).