casting pointers, executing from .data

[G.R.Tomasevich]

> > In articles <184 at 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