Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!bellcore!decvax!decwrl!amdcad!lll-crg!topaz!bentley!kwh
From: kwh@bentley.UUCP (KW Heuer)
Newsgroups: net.lang.c
Subject: Re: Arcane C hacks?
Message-ID: <600@bentley.UUCP>
Date: Wed, 26-Feb-86 11:14:41 EST
Article-I.D.: bentley.600
Posted: Wed Feb 26 11:14:41 1986
Date-Received: Fri, 28-Feb-86 21:49:31 EST
References: <184@bu-cs.UUCP>, <592@bentley.UUCP>, <1067@houxf.UUCP>
Organization: AT&T Bell Laboratories, Liberty Corner
Lines: 48

[ bu-cs!bzs (Barry Shein) ]
>> >declare a table something like:   int (*funtable[MAXFNS])() ;
>> >and just malloc the storage for the generated code.  ...  It should be
>> >quite portable (code generator aside) and is legal C.

[ bentley!kwh (Karl Heuer) ]
>> 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

[ houxf!jph (Jack Harkins) ]
>Huh???  This line of code DOES NOT cast a char * into an int....
>I have programs that use pointers to functions, some that run on 3B2/5's.

Sorry, you seem to have lost the context.  The original poster wanted to
malloc space for the CODE ITSELF, not the pointer table; i.e. do something
like
	funtable[0] = (int (*)())malloc(codesize);
and this line _does_ cast a (char *) (which is what malloc() returns)
into a function pointer.  (Actually a more likely sequence is
	char *s = malloc(codesize);
	s[0] = CLRW;  s[1] = R0;
	funtable[0] = (int (*)())s;
	n = (*funtable[0])();
or something like that.)

[ bentley!kwh (Karl Heuer) ]
>> 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.

[ houxf!jph (Jack Harkins) ]
>Whazat??
>
>MOST(not all) programs are pure in this environment, yes.  But that has
>nothing to do with being able to use a pointer to a function.  The code
>that is executed is actually in the shared text region; it is only the
>pointer to the function that is in the data area.

When I said "all programs are pure", I meant that on the 3b2 it is _not_
_possible_ to write an impure program (as far as I can determine).  The
code fragment above can be made to work on a VAX (even without "ld -N"),
but on the 3b2 it dies with a bus error.  I hope I've cleared this up.

To any would-be flamers: the alignment is appropriate; the bus error
occurs on the CALL instruction; don't flame me about what I'm "clearly"
doing wrong unless you can demonstrate a way to do it right.  On a 3b2.
I've already checked things pretty carefully, including the source code
in the kernel.