Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!umcp-cs!chris
From: chris@umcp-cs.UUCP (Chris Torek)
Newsgroups: net.unix-wizards
Subject: Re: Has dbm ever worked?
Message-ID: <3749@umcp-cs.UUCP>
Date: Wed, 8-Oct-86 10:26:33 EDT
Article-I.D.: umcp-cs.3749
Posted: Wed Oct  8 10:26:33 1986
Date-Received: Wed, 8-Oct-86 22:46:18 EDT
References: <240@ima.UUCP>
Distribution: net
Organization: Computer Sci. Dept, U of Maryland, College Park, MD
Lines: 30
Summary: Yes

In article <240@ima.UUCP> johnl@ima.UUCP (John R. Levine) writes:
>... It appears to me that nextkey() has never worked for databases
>larger than one block.  In the nextkey routine, it goes through
>some magic to get a key, and then (for reasonable reasons) checks
>to make sure that the key is in the data base and not the very
>first key.  Unfortunately, when it looks up the very first key,
>that uses the same buffer where the key it was looking at lived,
>and smashes it.

The 4.2 nextkey() does not work this way.  It uses the key to
calculate the proper block, then finds the next object in that
block (the one that follows the item given to nextkey).  If it
reaches the end of the block, it moves to the next block.

The 4.3 nextkey() does something entirely different and incompatible,
and therefore broken, though certainly more efficient.  In
particular, the 4.2 nextkey() would give you The Next Key after
its argument.  The 4.3 nextkey() gives you the next key after the
previous call to nextkey().  If all your calls to nextkey() are
sequential, this is equivalent.  Of all the programs that use dbm
or ndbm, I know of none that do not make sequential calls, for
whatever that is worth.

I submit that your vendor, like Berkeley, sought to `improve' Ken's
code, and, like Berkeley, broke it.  Unlike Berkeley, they failed
to test it.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1516)
UUCP:	seismo!umcp-cs!chris
CSNet:	chris@umcp-cs		ARPA:	chris@mimsy.umd.edu