Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!tut.cis.ohio-state.edu!ucbvax!hoptoad!tim
From: tim@hoptoad.uucp (Tim Maroney)
Newsgroups: comp.sys.mac.programmer
Subject: Re: HLock
Message-ID: <9348@hoptoad.uucp>
Date: 19 Dec 89 08:48:46 GMT
References: <3331@hub.UUCP> <9313@hoptoad.uucp> <1989Dec19.001739.17771@oracle.com>
Reply-To: tim@hoptoad.UUCP (Tim Maroney)
Organization: Eclectic Software, San Francisco
Lines: 33

In article <9313@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes:
>>Rect r;
>>r = (*theControl)->contrlRect;
>>RectRgn(myRgn, &r);

In article <1989Dec19.001739.17771@oracle.com> omullarn@oracle.com
(Oliver Mullarney) writes:
>as a way of avoiding using HLock and HUnlock. Not in this case. What you
>are handing to RectRgn is a pointer into a relocatable block. It may look
>like a legitimate pointer, but it is not, so this *can* crap out.

Wrong.  Look at the code again.  It's a pointer to a rectangle on the
stack, which is in no way relocatable.  Copying the rectangle out of the
relocatable block onto the stack prevents the passing of a pointer into
a relocatable block.  You seem to have read this as "Rect *r;
r = &(*theControl)->contrlRect; RectRgn(myRgn, r);" which would
indeed be unsafe -- but that's not what I typed.

>HLock and HUnlock are probably the best solution in this case, or the
>HGetState and HSetState calls. 

Nope, there's more overhead involved in the trap calls than in the
copying of eight bytes.  And there's also less "cognitive overhead"
if you avoid locking handles, since you never have to keep track
of when things are supposed to be locked.
-- 
Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com

FROM THE FOOL FILE:
"The negro slaves of the South are the happiest, and, in some sense, the
 freest people in the world.  The children and the aged and infirm work not
 at all, and yet have all the comforts and neccessaries of life provided for
 them." -- George Fitzhugh, CANNIBALS ALL! OR, SLAVES WITHOUT MASTERS, 1857