Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!unisoft!hoptoad!farcomp!murat
From: murat@farcomp.UUCP (Murat Konar)
Newsgroups: comp.sys.mac.programmer
Subject: Re: HLock Function List
Message-ID: <303@farcomp.UUCP>
Date: 28 Feb 91 03:28:23 GMT
References: <1991Feb20.042807.12553@ux1.cso.uiuc.edu> <3947@uakari.primate.wisc.edu> <12178@goofy.Apple.COM>
Reply-To: murat@farcomp.UUCP (Murat Konar)
Organization: Farallon Computing Inc. Berkeley, CA
Lines: 31


In  <12178@goofy.Apple.COM- lsr@Apple.com (Larry Rosenstein) writes:
-In  <3947@uakari.primate.wisc.edu-, bin@primate.wisc.edu (Brain in Neutral) writes:
--
-- It's safest to consider the list to be "all ToolBox calls", because
-- although not every call *today* has the potential to cause memory to
-- be moved, the list continues to expand over time.  A function that's
-- safe today might not be safe tomorrow.
-

-I think this is being overly cautious.  There's no way, for example, that
-SetRect, SetPt, HLock, BlockMore (to name a few) will ever move memory.

I tend to agree with this Brain fellow.  It's just defensive programming. 
You can't count on all the INIT's that patch traps to do so in a way 
that preserves their 'safeness.'  I do agree that SetRect et. al. will 
probably be safe forever.

Also, I don't believe the list in Inside Mac or the X-Ref is entirely 
accurate. To wit: FindWindow is not listed as a routine that can move 
memory.  However, in the course of its duties, FindWindow calls WDEFs.  
As far as I know, there are no restrictions on whether a WDEF can move 
memory.  If my WDEF happens to move memory in its hit routine, then 
FindWindow bocomes a routine that can move memory.

-Murat
-- 
____________________________________________________________________
Have a day. :^|             
Murat N. Konar	
murat@farcomp.UUCP             -or-          farcomp!murat@apple.com