Xref: utzoo comp.unix.wizards:16112 comp.lang.c:18646
Path: utzoo!yunexus!oz
From: oz@yunexus.UUCP (Ozan Yigit)
Newsgroups: comp.unix.wizards,comp.lang.c
Subject: Re: dbm/ndbm notes and some code.
Keywords: ndbm, sdbm, dbm, extendible-hashing.
Message-ID: <1915@yunexus.UUCP>
Date: 13 May 89 03:04:43 GMT
Article-I.D.: yunexus.1915
References: <1889@yunexus.UUCP> <6847@cbmvax.UUCP>
Reply-To: oz@yunexus.UUCP (Ozan Yigit)
Organization: York U. Communications Research & Development
Lines: 19

In article <6847@cbmvax.UUCP> grr@cbmvax.UUCP (George Robbins) writes:

>Say what?  Where are you going to save this potentially unbounded list of
>to be deleted keys?  Surely there is a better solution???

Right !!! :-) [I said there was a workaround. I did not say "practical"]
Actually, The solution is to simply watch (using the terminology of
ndbm.h) dbm_keyptr for deletions, and backspace it when the key
to be deleted is the one pointed by dbm_keyptr. So, when the dbm_nextkey
comes along and increments it, it will find the key now occupying the spot
of the deleted key. the "delpair" routine I posted has the very same
position adjustment.

oz
-- 
use the source, luke !!     	        Usenet:    oz@nexus.yorku.ca
uh... we forgot to tell you...          ......!uunet!utai!yunexus!oz
it is unintelligible, but hey, you      Bitnet: oz@[yulibra|yuyetti]
got it, for free (!).                   Phonet: +1 416 736-5257x3976