Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!usc!cs.utexas.edu!uunet!virtech!cpcahil
From: cpcahil@virtech.uucp (Conor P. Cahill)
Newsgroups: comp.lang.c
Subject: Re: Separate data and function address spaces
Message-ID: <1989Nov10.123828.2561@virtech.uucp>
Date: 10 Nov 89 12:38:28 GMT
References: <530@dftsrv.gsfc.nasa.gov> <225800239@uxe.cso.uiuc.edu> <10984@csli.Stanford.EDU>
Organization: Virtual Technologies Inc.
Lines: 27

In article <10984@csli.Stanford.EDU>, poser@csli.Stanford.EDU (Bill Poser) writes:
> 	Is there a reason why someone would write code like:
> 
> 	char *p;
> 	int fn();
> 	p = (char *)fn;
> 
> whose non-portability has been under discussion?

Yes, at least that kind of operation (where data and function pointers are 
converted an used).  I worked on a project that used shared memory to
implement shared libraries, so functions had to be in data space and the 
pointers to those functions were based upon the shmaddr returned by 
shmat().

This was definately not portable to every machine, but was usable on many 
system V.2 systems with just a bit of tweaking (mostly in the initialization
code and loader scripts).  Here the advantage of the non-portable code 
outweighed the non-portability, besides it was coded so that it could
be turn on/off at compile time, so if the system did not support it, we just
turned it off.

-- 
+-----------------------------------------------------------------------+
| Conor P. Cahill     uunet!virtech!cpcahil      	703-430-9247	!
| Virtual Technologies Inc.,    P. O. Box 876,   Sterling, VA 22170     |
+-----------------------------------------------------------------------+