Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!sdd.hp.com!hp-pcd!hpcvra.cv.hp.com!billw
From: billw@hpcvra.cv.hp.com. (William C Wickes)
Newsgroups: comp.sys.handhelds
Subject: Re: HP 48 Faster PGDIR
Message-ID: <25590170@hpcvra.cv.hp.com.>
Date: 6 Jun 91 21:41:32 GMT
References: <284dca48:3374comp.sys.handhelds@hpcvbbs.UUCP>
Organization: Hewlett-Packard Co., Corvallis, OR, USA
Lines: 27

An extra benefit of Joseph's method is that it can not only blow away a
directory instantly, but it can also blow away everything in main RAM
at no extra charge.

> Except for its improved speed, its action is exactly like PGDIR.

Not quite.  PGDIR is safe.

In my excellent book I explained what PGDIR does, not WHY it does it.
Guess what!  There isn't a better way!  What? you mean there's a
reason that PGDIR goes through all that agony?  Well, yes: directories
are not composite objects, and thus a directory in temporary memory,
such as might be created by PURGE, must not contain referenced
objects.  Garbage collection is doomed by such references, so PGDIR's
labor is to remove the directory without leaving any references to any
of its innards.  PURGE doesn't bother with such niceties, so it's not
allowed to handle directories.  Fooling it with null-named variables
is courting disaster.  FPGDIR may work safely most of the time if you
execute a system halt (ON-C) first, but even that's not 100%
bulletproof.

In case the above is too subtle for anyone, just take it that using FPGDIR
(i.e. creating a null-named variable, then purging a directory) is NOT
a good thing to do.

Bill Wickes
HP Corvallis