OK, so why _does_ ld resolve text against data?

[Doug Gwyn]

In article <3274 at skye.ed.ac.uk> richard at aiai.UUCP (Richard Tobin) writes:
> - It's useful for the linker to resolve these references.  Pointers
>   to procedures are often passed around as data, and it's often 
>   useful to be able to execute code in the data segment.  It might
>   be reasonable for the linker to *warn* about the latter case, or
>   require a flag.

Pointers to functions ARE data objects.
On the other hand, executing code from data space in inherently
nonportable, quite apart from machine instruction issues.
Presumably, code that is going to be ported around would not be
designed to execute code from data space.

>   ...  I had to debug a program which had run quite
>   happily until it was moved onto a machine which was a Sun yellow
>   pages client, and suddenly getpwent() was calling select(), which
>   the programmer had used as a variable name.

It's also fun when the Sun C compiler preprocessing changes your "sun"
variable into a "1" constant.

>   The solution is for
>   library routines to call other library routines under different
>   names (eg ones starting with __).

Most ANSI C-conscious UNIX vendors seem to favor a somewhat modified
version of this, with special support in the linker to avoid extra
overhead when the actual library select() function IS wanted.

>   On the other hand, it can be
>   useful to be able to replace a library routine and have other
>   library routines use your version.

I absolutely do not recommend this.  Implementations of the system
library may well have internal constraints that the application
programmer is unaware of, and replacing a library function can result
in obscure, sometimes subtle, malfunctions.