Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uwm.edu!zaphod.mps.ohio-state.edu!mips!apple!apple.com!casseres
From: casseres@apple.com (David Casseres)
Newsgroups: comp.sys.mac.programmer
Subject: Re: ROM doesn't unlock Handles (was: ROM unlocks Handles). LONG
Message-ID: <5968@internal.Apple.COM>
Date: 2 Jan 90 22:44:31 GMT
References: <3875@atr-la.atr.co.jp>
Sender: usenet@Apple.COM
Organization: Apple Computer, Inc.
Lines: 50

In article <3875@atr-la.atr.co.jp> alain@atr-la.atr.co.jp (Alain de 
Cheveigne) writes:
> From: shebanow@Apple.COM (Andrew Shebanow):
> >It is true that the lists of traps that may move or purge memory are out
> >of date, and that traps which currently are considered "safe" may become
> >"unsafe" sometime in the future. Our recommendation is that developers
> >err on the side of caution: if you are passing a dereferenced field
> >of a handle by address, either use a temporary or lock the handle. I
> >do feel that there are some calls which are "safe" to use dereferenced
> >handles with, like BlockMove, some string manipulation calls, etc. Use
> >your better judgment (or "Toolbox Karma", if you will).
> 
> Which is pretty lame.  Either a call is safe or it isn't.  If DTS
> can't guarantee it, who am I to judge, and how?  Trial and error?

A big part of the problem is patches.  Apple can (in principle) tell you 
exactly which traps are safe, but this doesn't help if your code winds up 
running on a system where safe traps have been patched by inits or other 
third-party code, and the patches are not safe.  Personally, I assume that 
no trap call is "safe."

> Other (non-ROM) subroutines are supposedly safe if they don't call the
> ROM.  But to be sure of this, you have to know what's inside a
> routine.  This defeats the principle of information hiding, so the
> code tends to be unreliable (even Apple can't seem to keep track of
> such side effects).
> 
> In addition, a call to a "harmless" subroutine can move memory if the
> subroutine is in an unloaded segment.  Bottom line: don't trust *any*
> routine, either Apple's or your own.

That's the bottom line, all right, but I want to point out that a great 
deal of pain can be avoided by a style of code design that finesses the 
problem by passing around handles, not pointers.  The whole point of a 
handle is that it is always valid.  Pass handles, and dereference them 
only when you have to; then you only have to lock occasionally.  Design 
your heap data structures accordingly.

In the kind of code you're worrying about, I'd say the overhead of 
dereferencing a handle many times instead of just once is going to be less 
than the overhead of a great deal of locking and unlocking.  Certainly the 
cognitive overhead is going to be less, and readability will be much 
better.

It's true that the Toolbox, especially older parts like QuickDraw, doesn't 
always encourage this style of coding, but this is not a major problem.

David Casseres

Exclaimer:  Hey!