Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!sharkey!edsews!uunet!munnari!rob
From: rob@munnari.oz (Robert Wallen)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Question on Handle locking example
Summary: Context is important too
Message-ID: <2658@munnari.oz>
Date: 28 Jan 89 23:54:51 GMT
References: <379@lclark.UUCP> <2580011@hpausla.HP.COM> <1219@sw1e.UUCP>
Reply-To: rob@munnari.UUCP (Robert Wallen)
Followup-To: comp.sys.mac.programmer
Organization: Comp Sci, Melbourne Uni, Australia
Lines: 39

In article <1219@sw1e.UUCP> uucibg@sw1e.UUCP ([5-3929] Brian Gilstrap) writes:
>I'm not clear on why function 'a' below would die.  This was posted recently
>as an example of how not to code.  I'm sure I'm missing something extremely
>obvious (it's late...), but please explain....
> [function a() deleted brevity]

The original posting also showed function b() which locked the handle it was
passed on entry, and unlocked it on exit.  Obviously, a() assumed that the
handle was still locked even though it was not.

Yes, its not as big a problem in C since the handle was being fully 
dereferenced each time.  However, if at any stage, a() had assumed h was locked
it would break.

Perhaps it becomes more apparent if I do this
a()
{
    Handle h;
    Ptr p;

    HLock(h);
    p = *h;         /* dereference for faster access */
    b(h);
    *p = ...        /* oops. we assumed that p would still be good because h */
    HUnlock(h);     /* was locked. since b unlocked it, it aint 8-( */
}
    
#ifdef ACCEPTING_FLAMES

Boy oh boy do these things get confused when you only post part of the original
The original posting did say 'its more of a problem in Pascal than C'.
The original posting did say 'code like this ... '
It also showed b() without which no-one could say why a() was not brilliant.

#endif

Hope that helps.  I know Jeff sometimes summarises what he is saying 'a little
too much'. Believe me, its better to shut him up quick than to let him rave
for hours 8-)  [ Hi Jeff ].