Path: utzoo!mnetor!tmsoft!torsqnt!jarvis.csri.toronto.edu!rutgers!ucsd!usc!samsung!aplcen!haven!uvaarpa!mcnc!ncsuvx!ecemwl!jnh
From: jnh@ecemwl.ncsu.edu (Joseph N. Hall)
Newsgroups: comp.sys.mac.programmer
Subject: Re: HLock and Think C 4.0
Message-ID: <4571@ncsuvx.ncsu.edu>
Date: 17 Nov 89 21:28:48 GMT
References: <18.25645e4f@bio.embnet.se>
Sender: news@ncsuvx.ncsu.edu
Reply-To: jnh@ecemwl.UUCP (Joseph N. Hall)
Organization: North Carolina State University
Lines: 19

In article <18.25645e4f@bio.embnet.se> Mats.Sundvall@bio.embnet.se writes:
>Just got bit by not locking a handle!
>
>In Think C 4.0 I define an object CTime as a instance of CObject. It has some
>integer fields and one Str255 field. The method Setstring does a strcpy
>from the parameter to the field. ...

Happened almost exactly like that to me.  A good general rule of thumb is
that in any situation where you use a dereferenced object member as an argument
to a library function (i.e., libfoo(foo->mbr)) you should HLock(foo) before
making the call.  "foo" in this case frequently turns out to be "this".

I'm not sure I like this "feature" of the THINK OOP system.  I wish there
were some "safety glue" or something that the compiler could insert in
these situations to do most or all of this handle locking for you ...
v   v sssss|| joseph hall                      || 4116 Brewster Drive
 v v s   s || jnh@ecemwl.ncsu.edu (Internet)   || Raleigh, NC  27606
  v   sss  || SP Software/CAD Tool Developer, Mac Hacker and Keyboardist
-----------|| Disclaimer: NCSU may not share my views, but is welcome to.