[comp.bugs.4bsd] NDBM HELP!

atkins@nbires.nbi.com (Brian Atkins) (12/24/87)

My database gets mucked up when I do a dbm_store with mode == DBM_REPLACE.
(under 4.3, ndbm in libc).  Is this a known bug?  Is there a fix?

Also, I can't seem to find any documentation on ndbm, or the algorithm
it uses. Does such exists?  If so, where?

Thanks in advance, this is killing me.

Brian Atkins		atkins@nbires.UUCP or atkins@nbires.NBI.COM
NBI Inc., P.O. Box 9001, Boulder CO 80301	(303) 938-2986

allyn@sdcsvax.UCSD.EDU (Allyn Fratkin) (12/24/87)

In article <61@cutter.nbi.com>, atkins@nbires.nbi.com (Brian Atkins) writes:
> My database gets mucked up when I do a dbm_store with mode == DBM_REPLACE.
> (under 4.3, ndbm in libc).  Is this a known bug?  Is there a fix?
> 
> Also, I can't seem to find any documentation on ndbm, or the algorithm
> it uses. Does such exists?  If so, where?

this is not a bug, really.  but it does violate the principle of least 
astonishment (at least it did for me).

the behavior you desribe is an artifact of the way ndbm works.  when it 
returns a pointer to the contents corresponding to a key, 
the pointer points into static storage in the page block (this is mentioned 
at the end of the manual page).

you're probably modifying the data in place (in the page block) and
then trying to update the information.  but the way dbm_store works
with the DBM_REPLACE option is that it first does a delete followed by a
regular store.  so your newly updated information is getting thrown away
(deleted).  you are then inserting whatever data is left in the page 
block instead of what you wanted.

i was bitten by this many times before i finally learned the hard way
how all of this worked.

anyway, the fix is to copy your data into another location before updating,
then do the dbm_store with the replace option.

the key (no pun intended) is just to remember that a store with DBM_REPLACE 
is exactly the equivalent of a dbm_delete and then a dbm_store with 
DBM_INSERT.  this "feature" is not mentioned in the manual.
-- 
 From the virtual mind of Allyn Fratkin            allyn@sdcsvax.ucsd.edu    or
                          EMU Project              {ucbvax, decvax, ihnp4}
                          U.C. San Diego                         !sdcsvax!allyn