1DBM_CLEARERR(3P) POSIX Programmer's Manual DBM_CLEARERR(3P)
2
6 This manual page is part of the POSIX Programmer's Manual. The Linux
7 implementation of this interface may differ (consult the corresponding
8 Linux manual page for details of Linux behavior), or the interface may
9 not be implemented on Linux.
10
13 dbm_clearerr, dbm_close, dbm_delete, dbm_error, dbm_fetch,
14 dbm_firstkey, dbm_nextkey, dbm_open, dbm_store — database functions
15
17 #include <ndbm.h>
18 int dbm_clearerr(DBM *db);
20 void dbm_close(DBM *db);
21 int dbm_delete(DBM *db, datum key);
22 int dbm_error(DBM *db);
23 datum dbm_fetch(DBM *db, datum key);
24 datum dbm_firstkey(DBM *db);
25 datum dbm_nextkey(DBM *db);
26 DBM *dbm_open(const char *file, int open_flags, mode_t file_mode);
27 int dbm_store(DBM *db, datum key, datum content, int store_mode);
28
30 These functions create, access, and modify a database.
31 A datum consists of at least two members, dptr and dsize. The dptr
33 member points to an object that is dsize bytes in length. Arbitrary
34 binary data, as well as character strings, may be stored in the object
35 pointed to by dptr.
36 A database shall be stored in one or two files. When one file is used,
38 the name of the database file shall be formed by appending the suffix
39 .db to the file argument given to dbm_open(). When two files are used,
40 the names of the database files shall be formed by appending the suf‐
41 fixes .dir and .pag respectively to the file argument.
42 The dbm_open() function shall open a database. The file argument to the
44 function is the pathname of the database. The open_flags argument has
45 the same meaning as the flags argument of open() except that a database
46 opened for write-only access opens the files for read and write access
47 and the behavior of the O_APPEND flag is unspecified. The file_mode
48 argument has the same meaning as the third argument of open().
49 The dbm_open() function need not accept pathnames longer than
51 {PATH_MAX}−4 bytes (including the terminating null), or pathnames with
52 a last component longer than {NAME_MAX}−4 bytes (excluding the termi‐
53 nating null).
54 The dbm_close() function shall close a database. The application shall
56 ensure that argument db is a pointer to a dbm structure that has been
57 returned from a call to dbm_open().
58 These database functions shall support an internal block size large
60 enough to support key/content pairs of at least 1023 bytes.
61 The dbm_fetch() function shall read a record from a database. The argu‐
63 ment db is a pointer to a database structure that has been returned
64 from a call to dbm_open(). The argument key is a datum that has been
65 initialized by the application to the value of the key that matches the
66 key of the record the program is fetching.
67 The dbm_store() function shall write a record to a database. The argu‐
69 ment db is a pointer to a database structure that has been returned
70 from a call to dbm_open(). The argument key is a datum that has been
71 initialized by the application to the value of the key that identifies
72 (for subsequent reading, writing, or deleting) the record the applica‐
73 tion is writing. The argument content is a datum that has been initial‐
74 ized by the application to the value of the record the program is writ‐
75 ing. The argument store_mode controls whether dbm_store() replaces any
76 pre-existing record that has the same key that is specified by the key
77 argument. The application shall set store_mode to either DBM_INSERT or
78 DBM_REPLACE. If the database contains a record that matches the key
79 argument and store_mode is DBM_REPLACE, the existing record shall be
80 replaced with the new record. If the database contains a record that
81 matches the key argument and store_mode is DBM_INSERT, the existing
82 record shall be left unchanged and the new record ignored. If the data‐
83 base does not contain a record that matches the key argument and
84 store_mode is either DBM_INSERT or DBM_REPLACE, the new record shall be
85 inserted in the database.
86 If the sum of a key/content pair exceeds the internal block size, the
88 result is unspecified. Moreover, the application shall ensure that all
89 key/content pairs that hash together fit on a single block. The
90 dbm_store() function shall return an error in the event that a disk
91 block fills with inseparable data.
92 The dbm_delete() function shall delete a record and its key from the
94 database. The argument db is a pointer to a database structure that has
95 been returned from a call to dbm_open(). The argument key is a datum
96 that has been initialized by the application to the value of the key
97 that identifies the record the program is deleting.
98 The dbm_firstkey() function shall return the first key in the database.
100 The argument db is a pointer to a database structure that has been
101 returned from a call to dbm_open().
102 The dbm_nextkey() function shall return the next key in the database.
104 The argument db is a pointer to a database structure that has been
105 returned from a call to dbm_open(). The application shall ensure that
106 the dbm_firstkey() function is called before calling dbm_nextkey().
107 Subsequent calls to dbm_nextkey() return the next key until all of the
108 keys in the database have been returned.
109 The dbm_error() function shall return the error condition of the data‐
111 base. The argument db is a pointer to a database structure that has
112 been returned from a call to dbm_open().
113 The dbm_clearerr() function shall clear the error condition of the
115 database. The argument db is a pointer to a database structure that has
116 been returned from a call to dbm_open().
117 The dptr pointers returned by these functions may point into static
119 storage that may be changed by subsequent calls.
120 These functions need not be thread-safe.
122
124 The dbm_store() and dbm_delete() functions shall return 0 when they
125 succeed and a negative value when they fail.
126 The dbm_store() function shall return 1 if it is called with a flags
128 value of DBM_INSERT and the function finds an existing record with the
129 same key.
130 The dbm_error() function shall return 0 if the error condition is not
132 set and return a non-zero value if the error condition is set.
133 The return value of dbm_clearerr() is unspecified.
135 The dbm_firstkey() and dbm_nextkey() functions shall return a key
137 datum. When the end of the database is reached, the dptr member of the
138 key is a null pointer. If an error is detected, the dptr member of the
139 key shall be a null pointer and the error condition of the database
140 shall be set.
141 The dbm_fetch() function shall return a content datum. If no record in
143 the database matches the key or if an error condition has been detected
144 in the database, the dptr member of the content shall be a null
145 pointer.
146 The dbm_open() function shall return a pointer to a database structure.
148 If an error is detected during the operation, dbm_open() shall return a
149 (DBM *)0.
150
152 No errors are defined.
153 The following sections are informative.
155
157 None.
158
160 The following code can be used to traverse the database:
161 for(key = dbm_firstkey(db); key.dptr != NULL; key = dbm_nextkey(db))
163 The dbm_* functions provided in this library should not be confused in
165 any way with those of a general-purpose database management system.
166 These functions do not provide for multiple search keys per entry, they
167 do not protect against multi-user access (in other words they do not
168 lock records or files), and they do not provide the many other useful
169 database functions that are found in more robust database management
170 systems. Creating and updating databases by use of these functions is
171 relatively slow because of data copies that occur upon hash collisions.
172 These functions are useful for applications requiring fast lookup of
173 relatively static information that is to be indexed by a single key.
174 Note that a strictly conforming application is extremely limited by
176 these functions: since there is no way to determine that the keys in
177 use do not all hash to the same value (although that would be rare), a
178 strictly conforming application cannot be guaranteed that it can store
179 more than one block's worth of data in the database. As long as a key
180 collision does not occur, additional data may be stored, but because
181 there is no way to determine whether an error is due to a key collision
182 or some other error condition (dbm_error() being effectively a Bool‐
183 ean), once an error is detected, the application is effectively limited
184 to guessing what the error might be if it wishes to continue using
185 these functions.
186 The dbm_delete() function need not physically reclaim file space,
188 although it does make it available for reuse by the database.
189 After calling dbm_store() or dbm_delete() during a pass through the
191 keys by dbm_firstkey() and dbm_nextkey(), the application should reset
192 the database by calling dbm_firstkey() before again calling dbm_nex‐
193 tkey(). The contents of these files are unspecified and may not be
194 portable.
195 Applications should take care that database pathname arguments speci‐
197 fied to dbm_open() are not prefixes of unrelated files. This might be
198 done, for example, by placing databases in a separate directory.
199 Since some implementations use three characters for a suffix and others
201 use four characters for a suffix, applications should ensure that the
202 maximum portable pathname length passed to dbm_open() is no greater
203 than {PATH_MAX}−4 bytes, with the last component of the pathname no
204 greater than {NAME_MAX}−4 bytes.
205
207 Previously the standard required the database to be stored in two
208 files, one file being a directory containing a bitmap of keys and hav‐
209 ing .dir as its suffix. The second file containing all data and having
210 .pag as its suffix. This has been changed not to specify the use of the
211 files and to allow newer implementations of the Berkeley DB interface
212 using a single file that have evolved while remaining compatible with
213 the application programming interface. The standard developers consid‐
214 ered removing the specific suffixes altogether but decided to retain
215 them so as not to pollute the application file name space more than
216 necessary and to allow for portable backups of the database.
217
219 None.
220
222 open()
223 The Base Definitions volume of POSIX.1‐2008, <ndbm.h>
225
227 Portions of this text are reprinted and reproduced in electronic form
228 from IEEE Std 1003.1, 2013 Edition, Standard for Information Technology
229 -- Portable Operating System Interface (POSIX), The Open Group Base
230 Specifications Issue 7, Copyright (C) 2013 by the Institute of Electri‐
231 cal and Electronics Engineers, Inc and The Open Group. (This is
232 POSIX.1-2008 with the 2013 Technical Corrigendum 1 applied.) In the
233 event of any discrepancy between this version and the original IEEE and
234 The Open Group Standard, the original IEEE and The Open Group Standard
235 is the referee document. The original Standard can be obtained online
236 at http://www.unix.org/online.html .
237 Any typographical or formatting errors that appear in this page are
239 most likely to have been introduced during the conversion of the source
240 files to man page format. To report such errors, see https://www.ker‐
241 nel.org/doc/man-pages/reporting_bugs.html .
242IEEE/The Open Group 2013 DBM_CLEARERR(3P)