Xref: utzoo comp.unix.questions:24222 comp.unix.wizards:23226 comp.lang.c:30698
Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!samsung!zaphod.mps.ohio-state.edu!sdd.hp.com!decwrl!ucbvax!ucbarpa.Berkeley.EDU!edward
From: edward@ucbarpa.Berkeley.EDU (Edward Wang)
Newsgroups: comp.unix.questions,comp.unix.wizards,comp.lang.c
Subject: Re: _why_ does the UNIX linker not distinguish text and data addresses???
Message-ID: <37909@ucbvax.BERKELEY.EDU>
Date: 1 Aug 90 10:38:55 GMT
References: <1990Jul30.104726.22660@mtcchi.uucp>
Sender: usenet@ucbvax.BERKELEY.EDU
Reply-To: edward@ucbarpa.Berkeley.EDU.UUCP (Edward Wang)
Distribution: na
Organization: University of California, Berkeley
Lines: 23

Well, it allows data to be executed.  Rather, the difference
between text and data is that text can be read-only and shared,
not that data is not executable.  Given that, it would be
incorrect for the linker to signal an error.

The only impact this has on the language is that global
variables and functions must share the same name space.
The compiler makes no judgement on where you put functions
or variables.  With -R, variables can end up in the text
segment.  Compiled C code can be linked with hand-written,
even self-modifying, assembly code.  Therefore, it would be
incorrect for the compiler to specify where an undefined
symbol should come from.

Your program has a C error, no different from declaring
a variable as an int in one place and as a float somewhere else.
True, the compiler should catch it, but the current organization
makes it difficult.  (Use lint.)  The correct C code
(* (void (*)()) &bogus)() generates the same binary.
There's no way for the linker to tell.

Anyway, it's not the linker's fault.  It's the compiler's fault.
If you consider lint to be part of the compiler, then it's your fault.