🚀 go-pugleaf

In article <8217@prls.UUCP> gardner@prls.UUCP (Robert Gardner) writes:
>I started working on segmenting a large program that uses function pointers
>rather extensively and got worried about assigning a function pointer
>in one segment, unloading that segment, and having it accessed later from
>another segment. Is the function pointer still valid?

Yes. What is actually being passed around is the reference to the function
in the jump table, just as you surmised.  The reason this works for static
function is, they go in the jump table too
(Think about it, they have to, see this example:)

static HiddenFunc(){}

ProcPtr PassOut(){
  return (PtocPtr) HiddenFunc;
}

-----------------------------
This is completely legal. The only way this can work is if PassOut() is
really returning the segment table reference.

==============
Caveat: suppose you pass out a reference that uses the segment loader's
jump table, suppose you unload the segment, and pass the address to an
operating system routine that runs at interrupt time (VBL task,
IOCompletion routine,  interrupt handler.) Well, the segment loader will
try to read the segment in, and the memory manager may be in an invalid
state: the bomb!
Moral: if you pass it to the operating system's interrupt system, make
sure it is in memory and stays in memory
=============
There is one case where this will get you into trouble: If you do things
at IAZNotify() time, the heap may be scrambled enough that the segment
table has already been destroyed. If you do this, you must be careful to
use a segment you KNOW is in the heap, and you must dereference it from
the jmp table to the real address (remember to skip the JMP instruction.)
yourself before you pass it.
Moral: You should take Apple's advice and not write IAZNotify routines.

P.S.: You posted to:
Newsgroups: comp.sys.ibm.pc,comp.sys.mac,comp.sys.atari.st

which is not appropriate for this kind of questions. This article is
going only to comp.sys.mac.


--- David Phillip Oster            --A Sun 3/60 makes a poor Macintosh II.
Arpa: oster@dewey.soe.berkeley.edu --A Macintosh II makes a poor Sun 3/60.
Uucp: {uwvax,decvax,ihnp4}!ucbvax!oster%dewey.soe.berkeley.edu