Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!cs.utexas.edu!ut-emx!chrisj
From: chrisj@ut-emx.UUCP (Chris Johnson)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Integer Size problem
Message-ID: <17542@ut-emx.UUCP>
Date: 23 Aug 89 22:04:51 GMT
References: <15141@dartvax.Dartmouth.EDU> <11689@cit-vax.Caltech.Edu> <1465@draken.nada.kth.se>
Reply-To: chrisj@emx.UUCP (Chris Johnson)
Organization: U.T. Austin Computation Center
Lines: 31

In article <1465@draken.nada.kth.se> d88-jwa@nada.kth.se (Jon W{tte) writes:
>In article <11689@cit-vax.Caltech.Edu> palmer@tybalt.caltech.edu.UUCP (David Palmer) writes:
>>A better way, clearer and probably faster, however is to just do:
>>	**(rect **)myHandle = myRect;
>>
>>You don't have to lock anything down, it is a single easy to understand
>
>Wrong. Incorrect. What happens if a interrupt happens between the set
>pointers and the block move instruction ? And this interrupt happens
>to shuffle memory ? LOCK THE HANDLES first ! ALWAYS !

Actually you don't need to lock anything down here.  Code running at the 
interrupt level is *forbidden* by Apple to use any calls that can move or 
purge memory.

I expect that this case is just *one* of the reasons that they're forbidden.

Of course, locking things down never hurts, and if you choose not to lock
blocks before you access them you have to be *extremely* careful not to make
any Toolbox or OS calls that might, directly or indirectly, move or purge
memory, thus causing your pointer to become invalid.  So, extreme caution 
should be used, but it actually *is* possible to access ulocked blocks safely.

The Inside Macintosh X-Ref contains the most up-to-date list of routines
that can move or purge memory that I know of.  In general, I'd say that you
should check *every* routine you use against that table -- there are some 
surprises there.  NumToString(), believe it or not, may move or purge memory,
for instance.  Once again, use extreme caution.

Cheers,
----Chris