logo

oasis-root

Compiled tree of Oasis Linux based on own branch at <https://hacktivis.me/git/oasis/> git clone https://anongit.hacktivis.me/git/oasis-root.git

dbm_clearerr.3p (11826B)


  1. '\" et
  2. .TH DBM_CLEARERR "3P" 2017 "IEEE/The Open Group" "POSIX Programmer's Manual"
  3. .\"
  4. .SH PROLOG
  5. This manual page is part of the POSIX Programmer's Manual.
  6. The Linux implementation of this interface may differ (consult
  7. the corresponding Linux manual page for details of Linux behavior),
  8. or the interface may not be implemented on Linux.
  9. .\"
  10. .SH NAME
  11. dbm_clearerr,
  12. dbm_close,
  13. dbm_delete,
  14. dbm_error,
  15. dbm_fetch,
  16. dbm_firstkey,
  17. dbm_nextkey,
  18. dbm_open,
  19. dbm_store
  20. \(em database functions
  21. .SH SYNOPSIS
  22. .LP
  23. .nf
  24. #include <ndbm.h>
  25. .P
  26. int dbm_clearerr(DBM *\fIdb\fP);
  27. void dbm_close(DBM *\fIdb\fP);
  28. int dbm_delete(DBM *\fIdb\fP, datum \fIkey\fP);
  29. int dbm_error(DBM *\fIdb\fP);
  30. datum dbm_fetch(DBM *\fIdb\fP, datum \fIkey\fP);
  31. datum dbm_firstkey(DBM *\fIdb\fP);
  32. datum dbm_nextkey(DBM *\fIdb\fP);
  33. DBM *dbm_open(const char *\fIfile\fP, int \fIopen_flags\fP, mode_t \fIfile_mode\fP);
  34. int dbm_store(DBM *\fIdb\fP, datum \fIkey\fP, datum \fIcontent\fP, int \fIstore_mode\fP);
  35. .fi
  36. .SH DESCRIPTION
  37. These functions create, access, and modify a database.
  38. .P
  39. A
  40. .BR datum
  41. consists of at least two members,
  42. .IR dptr
  43. and
  44. .IR dsize .
  45. The
  46. .IR dptr
  47. member points to an object that is
  48. .IR dsize
  49. bytes in length. Arbitrary binary data, as well as character strings,
  50. may be stored in the object pointed to by
  51. .IR dptr .
  52. .P
  53. A database shall be stored in one or two files. When one file is used,
  54. the name of the database file shall be formed by appending the suffix
  55. .BR .db
  56. to the
  57. .IR file
  58. argument given to
  59. \fIdbm_open\fR().
  60. When two files are used, the names of the database files shall be
  61. formed by appending the suffixes
  62. .BR .dir
  63. and
  64. .BR .pag
  65. respectively to the
  66. .IR file
  67. argument.
  68. .P
  69. The
  70. \fIdbm_open\fR()
  71. function shall open a database. The
  72. .IR file
  73. argument to the function is the pathname of the database. The
  74. .IR open_flags
  75. argument has the same meaning as the
  76. .IR flags
  77. argument of
  78. \fIopen\fR()
  79. except that a database opened for write-only access opens the files for
  80. read and write access and the behavior of the O_APPEND flag
  81. is unspecified. The
  82. .IR file_mode
  83. argument has the same meaning as the third argument of
  84. \fIopen\fR().
  85. .P
  86. The
  87. \fIdbm_open\fR()
  88. function need not accept pathnames longer than
  89. {PATH_MAX}\-4
  90. bytes (including the terminating null), or pathnames with a last
  91. component longer than
  92. {NAME_MAX}\-4
  93. bytes (excluding the terminating null).
  94. .P
  95. The
  96. \fIdbm_close\fR()
  97. function shall close a database. The application shall ensure that
  98. argument
  99. .IR db
  100. is a pointer to a
  101. .BR dbm
  102. structure that has been returned from a call to
  103. \fIdbm_open\fR().
  104. .P
  105. These database functions shall support an internal block size large
  106. enough to support key/content pairs of at least 1\|023 bytes.
  107. .P
  108. The
  109. \fIdbm_fetch\fR()
  110. function shall read a record from a database. The argument
  111. .IR db
  112. is a pointer to a database structure that has been returned from a call
  113. to
  114. \fIdbm_open\fR().
  115. The argument
  116. .IR key
  117. is a
  118. .BR datum
  119. that has been initialized by the application to the value of
  120. the key that matches the key of the record the program is fetching.
  121. .P
  122. The
  123. \fIdbm_store\fR()
  124. function shall write a record to a database. The argument
  125. .IR db
  126. is a pointer to a database structure that has been returned from a call
  127. to
  128. \fIdbm_open\fR().
  129. The argument
  130. .IR key
  131. is a
  132. .BR datum
  133. that has been initialized by the application to the value of the key
  134. that identifies (for subsequent reading, writing, or deleting) the
  135. record the application is writing. The argument
  136. .IR content
  137. is a
  138. .BR datum
  139. that has been initialized by the application to the value of the record
  140. the program is writing. The argument
  141. .IR store_mode
  142. controls whether
  143. \fIdbm_store\fR()
  144. replaces any pre-existing record that has the same key that is
  145. specified by the
  146. .IR key
  147. argument. The application shall set
  148. .IR store_mode
  149. to either DBM_INSERT or DBM_REPLACE. If the database contains a record
  150. that matches the
  151. .IR key
  152. argument and
  153. .IR store_mode
  154. is DBM_REPLACE, the existing record shall be replaced with the new
  155. record. If the database contains a record that matches the
  156. .IR key
  157. argument and
  158. .IR store_mode
  159. is DBM_INSERT, the existing record shall be left unchanged and the new
  160. record ignored. If the database does not contain a record that matches
  161. the
  162. .IR key
  163. argument and
  164. .IR store_mode
  165. is either DBM_INSERT or DBM_REPLACE, the new record shall be inserted
  166. in the database.
  167. .P
  168. If the sum of a key/content pair exceeds the internal block size, the
  169. result is unspecified. Moreover, the application shall ensure that all
  170. key/content pairs that hash together fit on a single block. The
  171. \fIdbm_store\fR()
  172. function shall return an error in the event that a disk block fills
  173. with inseparable data.
  174. .P
  175. The
  176. \fIdbm_delete\fR()
  177. function shall delete a record and its key from the database. The
  178. argument
  179. .IR db
  180. is a pointer to a database structure that has been returned from a call
  181. to
  182. \fIdbm_open\fR().
  183. The argument
  184. .IR key
  185. is a
  186. .BR datum
  187. that has been initialized by the application to the value of
  188. the key that identifies the record the program is deleting.
  189. .P
  190. The
  191. \fIdbm_firstkey\fR()
  192. function shall return the first key in the database. The argument
  193. .IR db
  194. is a pointer to a database structure that has been returned from a call
  195. to
  196. \fIdbm_open\fR().
  197. .P
  198. The
  199. \fIdbm_nextkey\fR()
  200. function shall return the next key in the database. The argument
  201. .IR db
  202. is a pointer to a database structure that has been returned from a call
  203. to
  204. \fIdbm_open\fR().
  205. The application shall ensure that the
  206. \fIdbm_firstkey\fR()
  207. function is called before calling
  208. \fIdbm_nextkey\fR().
  209. Subsequent calls to
  210. \fIdbm_nextkey\fR()
  211. return the next key until all of the keys in the database have been
  212. returned.
  213. .P
  214. The
  215. \fIdbm_error\fR()
  216. function shall return the error condition of the database. The argument
  217. .IR db
  218. is a pointer to a database structure that has been returned from a call
  219. to
  220. \fIdbm_open\fR().
  221. .P
  222. The
  223. \fIdbm_clearerr\fR()
  224. function shall clear the error condition of the database. The argument
  225. .IR db
  226. is a pointer to a database structure that has been returned from a call
  227. to
  228. \fIdbm_open\fR().
  229. .P
  230. The
  231. .IR dptr
  232. pointers returned by these functions may point into static storage that
  233. may be changed by subsequent calls.
  234. .P
  235. These functions need not be thread-safe.
  236. .SH "RETURN VALUE"
  237. The
  238. \fIdbm_store\fR()
  239. and
  240. \fIdbm_delete\fR()
  241. functions shall return 0 when they succeed and a negative value when
  242. they fail.
  243. .P
  244. The
  245. \fIdbm_store\fR()
  246. function shall return 1 if it is called with a
  247. .IR flags
  248. value of DBM_INSERT and the function finds an existing record with the
  249. same key.
  250. .P
  251. The
  252. \fIdbm_error\fR()
  253. function shall return 0 if the error condition is not set and return a
  254. non-zero value if the error condition is set.
  255. .P
  256. The return value of
  257. \fIdbm_clearerr\fR()
  258. is unspecified.
  259. .P
  260. The
  261. \fIdbm_firstkey\fR()
  262. and
  263. \fIdbm_nextkey\fR()
  264. functions shall return a key
  265. .BR datum .
  266. When the end of the database is reached, the
  267. .IR dptr
  268. member of the key is a null pointer. If an error is detected, the
  269. .IR dptr
  270. member of the key shall be a null pointer and the error condition of
  271. the database shall be set.
  272. .P
  273. The
  274. \fIdbm_fetch\fR()
  275. function shall return a content
  276. .BR datum .
  277. If no record in the database matches the key or if an error condition
  278. has been detected in the database, the
  279. .IR dptr
  280. member of the content shall be a null pointer.
  281. .P
  282. The
  283. \fIdbm_open\fR()
  284. function shall return a pointer to a database structure. If an error
  285. is detected during the operation,
  286. \fIdbm_open\fR()
  287. shall return a (\c
  288. .BR "DBM *" )0.
  289. .SH ERRORS
  290. No errors are defined.
  291. .LP
  292. .IR "The following sections are informative."
  293. .SH EXAMPLES
  294. None.
  295. .SH "APPLICATION USAGE"
  296. The following code can be used to traverse the database:
  297. .sp
  298. .RS 4
  299. .nf
  300. for(key = dbm_firstkey(db); key.dptr != NULL; key = dbm_nextkey(db))
  301. .fi
  302. .P
  303. .RE
  304. .P
  305. The
  306. .IR dbm_ *
  307. functions provided in this library should not be confused in any way
  308. with those of a general-purpose database management system. These
  309. functions do not provide for multiple search keys per entry, they do
  310. not protect against multi-user access (in other words they do not lock
  311. records or files), and they do not provide the many other useful
  312. database functions that are found in more robust database management
  313. systems. Creating and updating databases by use of these functions is
  314. relatively slow because of data copies that occur upon hash
  315. collisions. These functions are useful for applications requiring fast
  316. lookup of relatively static information that is to be indexed by a
  317. single key.
  318. .P
  319. Note that a strictly conforming application is extremely limited by
  320. these functions: since there is no way to determine that the keys in
  321. use do not all hash to the same value (although that would be rare), a
  322. strictly conforming application cannot be guaranteed that it can store
  323. more than one block's worth of data in the database. As long as a key
  324. collision does not occur, additional data may be stored, but because
  325. there is no way to determine whether an error is due to a key collision
  326. or some other error condition (\c
  327. \fIdbm_error\fR()
  328. being effectively a Boolean), once an error is detected, the
  329. application is effectively limited to guessing what the error might be
  330. if it wishes to continue using these functions.
  331. .P
  332. The
  333. \fIdbm_delete\fR()
  334. function need not physically reclaim file space, although it does make
  335. it available for reuse by the database.
  336. .P
  337. After calling
  338. \fIdbm_store\fR()
  339. or
  340. \fIdbm_delete\fR()
  341. during a pass through the keys by
  342. \fIdbm_firstkey\fR()
  343. and
  344. \fIdbm_nextkey\fR(),
  345. the application should reset the database by calling
  346. \fIdbm_firstkey\fR()
  347. before again calling
  348. \fIdbm_nextkey\fR().
  349. The contents of these files are unspecified and may not be portable.
  350. .P
  351. Applications should take care that database pathname arguments
  352. specified to
  353. \fIdbm_open\fR()
  354. are not prefixes of unrelated files. This might be done, for example,
  355. by placing databases in a separate directory.
  356. .P
  357. Since some implementations use three characters for a suffix and others
  358. use four characters for a suffix, applications should ensure that the
  359. maximum portable pathname length passed to
  360. \fIdbm_open\fR()
  361. is no greater than
  362. {PATH_MAX}\-4
  363. bytes, with the last component of the pathname no greater than
  364. {NAME_MAX}\-4
  365. bytes.
  366. .SH RATIONALE
  367. Previously the standard required the database to be stored in two
  368. files, one file being a directory containing a bitmap of keys and
  369. having
  370. .BR .dir
  371. as its suffix. The second file containing all data and having
  372. .BR .pag
  373. as its suffix. This has been changed not to specify the use of the
  374. files and to allow newer implementations of the Berkeley DB interface
  375. using a single file that have evolved while remaining compatible with
  376. the application programming interface. The standard developers
  377. considered removing the specific suffixes altogether but decided to
  378. retain them so as not to pollute the application file name space more
  379. than necessary and to allow for portable backups of the database.
  380. .SH "FUTURE DIRECTIONS"
  381. None.
  382. .SH "SEE ALSO"
  383. .IR "\fIopen\fR\^(\|)"
  384. .P
  385. The Base Definitions volume of POSIX.1\(hy2017,
  386. .IR "\fB<ndbm.h>\fP"
  387. .\"
  388. .SH COPYRIGHT
  389. Portions of this text are reprinted and reproduced in electronic form
  390. from IEEE Std 1003.1-2017, Standard for Information Technology
  391. -- Portable Operating System Interface (POSIX), The Open Group Base
  392. Specifications Issue 7, 2018 Edition,
  393. Copyright (C) 2018 by the Institute of
  394. Electrical and Electronics Engineers, Inc and The Open Group.
  395. In the event of any discrepancy between this version and the original IEEE and
  396. The Open Group Standard, the original IEEE and The Open Group Standard
  397. is the referee document. The original Standard can be obtained online at
  398. http://www.opengroup.org/unix/online.html .
  399. .PP
  400. Any typographical or formatting errors that appear
  401. in this page are most likely
  402. to have been introduced during the conversion of the source files to
  403. man page format. To report such errors, see
  404. https://www.kernel.org/doc/man-pages/reporting_bugs.html .