Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!dali.cs.montana.edu!uakari.primate.wisc.edu!sdd.hp.com!mips!apple!agate!dog.ee.lbl.gov!elf.ee.lbl.gov!torek
From: torek@elf.ee.lbl.gov (Chris Torek)
Newsgroups: comp.unix.programmer
Subject: Re: NDBM and ME
Message-ID: <13080@dog.ee.lbl.gov>
Date: 11 May 91 06:08:01 GMT
References: <GUEST.91May10124944@geech.ai.mit.edu> <ADRIANHO.91May10173137@barkley.berkeley.edu>
Reply-To: torek@elf.ee.lbl.gov (Chris Torek)
Distribution: usa
Organization: Lawrence Berkeley Laboratory, Berkeley
Lines: 33
X-Local-Date: Fri, 10 May 91 23:08:01 PDT

In article <ADRIANHO.91May10173137@barkley.berkeley.edu>
adrianho@barkley.berkeley.edu (Adrian J Ho) writes:
[a bunch of correct stuff]
>You now have a single string with all 4 fields that can be used in an
>NDBM record.

Note that ndbm places a (fairly small) limit on the size of any
single <key+content> pair (4096 bytes, minus overhead; this comes
to 4090 bytes for a page with one pair [1 count + 2 offsets, all
shorts, consumes 6 bytes]).

In general, you hand ndbm a blob of bytes as a content and a
separate blob of bytes as a key.  Some arbitrary time later, you
hand ndbm a blob of bytes as a key and it gives you back a blob
of bytes as a content.  The returned content is *not* at the same
`place' as the original, and is probably not at the same alignment.
Thus, for instance,

	datum.dptr = (char *)&foo;
	datum.size = sizeof(int);
	err = store(key, datum);

is OK, but

	datum = fetch(key);
	if (datum.dptr == NULL) ... handle not found ...;
	if (datum.dsize != sizeof(int)) ... handle corrupted database ...;
	foo = *(int *)datum.dptr;

is not, because `datum.dptr' may not be correctly aligned.
-- 
In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 415 486 5427)
Berkeley, CA		Domain:	torek@ee.lbl.gov