Path: utzoo!attcan!uunet!kddlab!atrpost!atr-la!alain
From: alain@atr-la.atr.co.jp (Alain de Cheveigne)
Newsgroups: comp.sys.mac.programmer
Subject: Re: How to Argue Technical Points (was Re: Tail patches)
Message-ID: <3838@atr-la.atr.co.jp>
Date: 3 Dec 89 06:19:04 GMT
References: <2744@dogie.macc.wisc.edu>
Organization: ATR International,Japan
Lines: 40
In-reply-to: yahnke@vms.macc.wisc.edu's message of 30 Nov 89 17:43:51 GMT


yahnke@vms.macc.wisc.edu writes:
>Apple documents all traps that may move memory, as an aid to promote
>safe programming practices. Would it make any sense or be any help 
>if Apple were to do a similar list? How about a tech note that
>documents which traps are patched, and maybe for what reason, so
>as to guide those who will inevitably go and patch things in spite
>of Apple's admonitions?
>
>That would seem to me to be an 'official' way for Apple to say, 
>"Don't tail patch, but if you do - here's what to watch out for..."
>
>>>>      Internet: yahnke@macc.wisc.edu        <<<
>>>>   Mille voix chuchottent <<c'est vrai>>    <<<

How about a similar list for traps that *unlock* handles ?  

It took me all of a long time to learn that any routine that dereferences
handles should start with HGetState (instead of just HLock), and end with 
HSetState (instead of HUnlock).

The reason is this: if the routine calls HUnlock on exit, it leaves
handles unlocked for the code that follows the routine call.  This is
a nice source of tough bugs.  If instead routines just call HLock, 
leaving the caller to do the unlocking, chances are a few handles will
be missed and remain locked, cluttering the heap.

If you use HGetState and HSetState instead, the routine leaves all handles
just the way they were before the routine was called.  The caller doesn't
have to know how the callee does his stuff, which is the way it should be.

But it seems that some ROM routines don't know it, and unlock handles 
behind one's back.  A list of those would be nice.

And how about a note about why HGetState and HSetState are useful ? (or
have I missed it ?)


Alain de Cheveigne,
alain@atr-la.atr.co.jp