Xref: utzoo comp.unix.wizards:16089 comp.lang.c:18626
Path: utzoo!attcan!uunet!cbmvax!grr
From: grr@cbmvax.UUCP (George Robbins)
Newsgroups: comp.unix.wizards,comp.lang.c
Subject: Re: dbm/ndbm notes and some code.
Keywords: ndbm, sdbm, dbm, extendible-hashing.
Message-ID: <6847@cbmvax.UUCP>
Date: 12 May 89 09:06:34 GMT
References: <1889@yunexus.UUCP>
Reply-To: grr@cbmvax.UUCP (George Robbins)
Organization: Commodore Technology, West Chester, PA
Lines: 20

In article <1889@yunexus.UUCP> oz@yunexus.UUCP (Ozan Yigit) writes:
> During my development of sdbm, a ndbm/dbm substitute (soon to beta: do not
> send mail), I have found one bug that has gone unnoticed on probably most
> of ndbm/dbm implementations.  One can write a simple workaround to this,
> but a bug is a bug nevertheless.  Remember that line from the man page: 
... 
> This is where the "database traversal" turns into a pumpkin.  Because of
> internal caching of the key position for dbm_nextkey (dbm_keyptr ??),
> which is appearently NOT adjusted for deletions, this traversal will never
> display the key right after the one just deleted. Workaround is to save
> all keys to be deleted, then perform all deletions once the sequential
> traversal is complete.

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

-- 
George Robbins - now working for,	uucp: {uunet|pyramid|rutgers}!cbmvax!grr
but no way officially representing	arpa: cbmvax!grr@uunet.uu.net
Commodore, Engineering Department	fone: 215-431-9255 (only by moonlite)