Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/17/84; site twitch.UUCP
Path: utzoo!watmath!clyde!cbosgd!ihnp4!twitch!grt
From: grt@twitch.UUCP ( G.R.Tomasevich)
Newsgroups: net.lang.c
Subject: casting pointers, executing from .data
Message-ID: <285@twitch.UUCP>
Date: Thu, 27-Feb-86 12:53:41 EST
Article-I.D.: twitch.285
Posted: Thu Feb 27 12:53:41 1986
Date-Received: Fri, 28-Feb-86 22:51:16 EST
References: <184@bu-cs.UUCP>, <592@bentley.UUCP> <1067@houxf.UUCP>
Organization: AT&T Bell Labs, Holmdel
Lines: 29

> > In articles <184@bu-cs.UUCP> bu-cs!bzs (Barry Shein) writes:
> > ...
> > Well, some compilers will dislike the attempt to cast a (char *) into
> > a (int (*)()) ; in fact I think some will call it an outright error
> 
> Jack Harkins (houxf!jph)
> Huh???
> 
> This line of code DOES NOT cast a char * into an int. It is declaring

He did not say 'int'; look at that declaration again.

> > because all programs are pure -- you can't goto/call data space, nor
> > can you read from the instruction stream.  Some sort of chastity belt
> > in the hardware, I think.
> 
> Whazat??

True.  What he means is that you cannot generate code in some array,
as from an assembler built into your program, and then jump into it.
I wrote a FORTH-like language, but I had to stick to using C functions
for all primitives because of that restriction.  It is not possible to
assemble new words into which one can transfer control.  One could set
a pointer to a function equal to the address of an array, but if you
enter that function, you go to that address in the instruction space,
not in the data space.
-- 
	George Tomasevich, ihnp4!twitch!grt
	AT&T Bell Laboratories, Holmdel, NJ