DBM(3B) DBM(3B)
dbm: dbminit, dbminit64, dbmclose, dbmclose64, fetch, fetch64, store,
store64, delete, delete64, firstkey, firstkey64, nextkey, nextkey64 -
data base subroutines
#include <dbm.h>
typedef struct {
char *dptr;
int dsize;
} datum;
int dbminit(const char *file);
int dbminit64(const char *file);
void dbmclose(void);
void dbmclose64(void);
datum fetch(datum key);
datum fetch64(datum key);
int store(datum key, datum content);
int store64(datum key, datum content);
int delete(datum key);
int delete64(datum key);
datum firstkey(void);
datum firstkey64(void);
datum nextkey(datum key);
datum nextkey64(datum key);
Note: the dbm library has been superseded by ndbm(3B), and is now
implemented using ndbm. These functions maintain key/content pairs in a
data base. The dbm functions will handle very large (a billion blocks)
databases and will access a keyed item in one or two file system
accesses. The dbm64 routines are identical to their dbm counterparts
except that they can be used to operate on data bases larger than 2
Gigabytes.
Page 1
DBM(3B) DBM(3B)
Keys and contents are described by the datum typedef. A datum specifies
a string of dsize bytes pointed to by dptr. Arbitrary binary data, as
well as normal ASCII strings, are allowed. The data base is stored in
two files. One file is a directory containing a bit map and has `.dir'
as its suffix. The second file contains all data and has `.pag' as its
suffix.
Before a database can be accessed, it must be opened by dbminit. At the
time of this call, the files file.dir and file.pag must exist. (An empty
database is created by creating zero-length `.dir' and `.pag' files.)
Once open, the data stored under a key is accessed by fetch and data is
placed under a key by store. A key (and its associated contents) is
deleted by delete. A linear pass through all keys in a database may be
made, in an (apparently) random order, by use of firstkey and nextkey.
Firstkey will return the first key in the database. With any key nextkey
will return the next key in the database. The following code will
traverse the data base:
for (key = firstkey(); key.dptr != NULL; key = nextkey(key))
All functions that return an int indicate errors with negative values. A
zero return indicates ok. Routines that return a datum indicate errors
with a null (0) dptr.
Some error conditions will set errno. These are: ENOMEM: runtime memory
allocation failed; EPERM: file permissions don't match the process
euid/egid permissions; EINVAL: key+data sizes for dbm_store exceed the
internal block size; EFBIG: hash table overflow would cause the maximum
dbm file size to be exceeded.
ndbm(3B) and Berkeley db: dbopen(3)
Dptr pointers returned by these subroutines point into static storage
that is changed by subsequent calls.
dbm databases may not be portable across machines with different
alignment restrictions or different byte sexes.
Dptr pointers returned by these subroutines point into possibly non word
aligned storage. You cannot assume that you can cast the Dptr pointer
into an arbitrary data type and dereference it. This is a general rule
in ANSI-C rather than dbm specific, but users often hit it while using
dbm.
Page 2
DBM(3B) DBM(3B)
The sum of the sizes of a key/content pair must not exceed the internal
block size minus the dbm small book-keeping overhead (currently _PBLKSIZ
- 6 = 1018 bytes). Moreover all key/content pairs that hash together
must fit on a single block. For a dbm-like implementation with much less
size limitations, check out dbopen(3) (Berkeley DB).
Store will return an error in the event that a disk block fills with
inseparable data.
Delete does not physically reclaim file space, although it does make it
available for reuse.
The order of keys presented by firstkey and nextkey depends on a hashing
function, not on anything interesting.
PPPPaaaaggggeeee 3333 [ Back ]
|
