Path: utzoo!attcan!uunet!dino!ux1.cso.uiuc.edu!brutus.cs.uiuc.edu!apple!well!oster
From: oster@well.sf.ca.us (David Phillip Oster)
Newsgroups: comp.sys.mac.programmer
Subject: Re: ThinkC's handling of CODE resources.
Message-ID: <19100@well.sf.ca.us>
Date: 18 Jul 90 10:33:44 GMT
References: <1990Jul10.150057.24765@hod.uit.no> <3806@adobe.UUCP>
Organization: Whole Earth 'Lectronic Link, Sausalito, CA
Lines: 21

In article <3806@adobe.UUCP> jholt@adobe.com (Joe Holt) writes:
>This reminds me of Microsoft Windows 3.0's approach to code segments.  They
>*can* move around between calls, but Windows has a daemon which actually
>walks the return stack and patches addresses so that they jive.  Zowie.

Ouch.

My C coding style uses lots of pointers to functions as arguments, and 
lots of data structures using pointers to functions. I can understand walking
the calling stack looking at the return addresses and fixing them up, but
unless the C compiler pushes a type descriptor for every argument, it can't
tell if an arbitrary argument is a long integer or a procedure pointer. How
is it going to know to adjust it? And how about pointers sitting in data
structures just waiting to be executed? I suppose the C compiler could put
every entrypoint it knew about into a jump table, but then its assembler would
have to include an ENTRYPOINT meta command, so I could create entrypoints
in assembly langauge that didn't use the C calling conventions. What a 
nightmare!
-- 
-- David Phillip Oster - Note new address. Old one has gone Bye Bye.
-- oster@well.sf.ca.us = {backbone}!well!oster