Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!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: <13658@smoke.BRL.MIL> Date: 23 Aug 90 20:17:27 GMT References: <37909@ucbvax.BERKELEY.EDU> <930@eplunix.UUCP> <3274@skye.ed.ac.uk> Organization: U.S. Army Ballistic Research Laboratory, APG, MD. Lines: 37 In article <3274@skye.ed.ac.uk> richard@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.