🚀 go-pugleaf

In my AmigaLINE on AmigaDOS locks, I stated a rule which has
since been proved to be incorrect:

Bad version with the erroneous text noted:

        NEVER UnLock any lock given to you by either
                                              xxxxxx
        CurrentDir() or ParentDir().  ONLY UnLock a
                     xxxxxxxxxxxxxx
        lock provided to you by Lock() or DupLock() 
	or ParentDir() or CreateDir() or any other
	^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
	function that actually CREATES a lock.
	^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        Those BELONG to you.  The others just might
        have been created by the system and it will
        not realize you have killed them -- when it
        tries to reuse them, the GURU may visit.


DELETE the "either" and the "or ParentDir()" where shown ("x"), 
and then add the sentence fragment that reference ParentDir() 
and CreateDir() where shown by ("^"), and the statements are correct.

In other words, only unlock any lock that YOU caused to be CREATED.

Matt Dillon noticed this and via priority EMAIL he reminded me
that ParentDir() returns a BPTR to a NEW LOCK.  Therefore you own
it and are responsible for seeing to it that you get rid of it
when you exit.   THANKS MATT!!!!

Sorry if there was any confusion.  I had incorrectly remembered
things as though ParentDir() moved you up the directory tree.  Aarrgghh,
what a bad memory.  Well, that is (so far) the only problem that has surfaced
in reply to that AmigaLINE.

Oh, yes, before I forget, there is a program on an early FISH disk
Named "LockMon" that I recall seeing that is supposed to tell you
if you exit with more locks (or fewer too I guess) than what you
started with.  I figure that would be a good thing to experiment
with for new DOS'ers.

And the question about BPTR's from AmigaDOS, yes, AmigaDOS handles
BPTR's and BSTR's (BPTR's to BCPL strings which have the length
in the first byte, followed by the string, non-null-terminated).
Declaring something as a ULONG when it is really a BPTR or BSTR
is ok, but to be technically accurate (and perhaps for public-distributed
code, helpful to the new user) one might consider using the appropriate
declaration.  In the Programmers' Guide, I occasionally specified
LONG GfxBase, and sometimes declared it as struct GfxBase *GfxBase.
The compiler does not care, but to make it easier to trace trouble
later on, or to modify the code if one of the variables in these
"base" areas are required, it buys a lot if the right declaration
is used in the first place.

Rob Peck