This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: [PATCH v1] Port ndbm
- From: "Craig Howland via newlib" <newlib at sourceware dot org>
- To: <newlib at sourceware dot org>
- Date: Wed, 10 Jul 2019 12:44:37 -0400
- Subject: Re: [PATCH v1] Port ndbm
- References: <20190710085550.1106-1-vaibhavgupta40@gmail.com>
- Reply-to: Craig Howland <howland at LGSInnovations dot com>
On 7/10/19 4:55 AM, Vaibhav Gupta wrote:
---
newlib/libc/include/ndbm.h | 93 ++++++++++++++
newlib/libc/search/Makefile.am | 1 +
newlib/libc/search/ndbm.c | 217 +++++++++++++++++++++++++++++++++
3 files changed, 311 insertions(+)
create mode 100644 newlib/libc/include/ndbm.h
create mode 100644 newlib/libc/search/ndbm.c
diff --git a/newlib/libc/include/ndbm.h b/newlib/libc/include/ndbm.h
...
+typedef struct {
+ void *dptr;
+ int dsize; /* XXX Should be size_t according to 1003.1-2008. */
If it is supposed to be size_t, then why isn't it? I did verify that POSIX does
specify size_t. (Newlib is starting new here, so it would seem to make sense to
make it right. Does BSD have int just for legacy compatibility reasons?)
+} datum;
+
What about documentation (i.e. man page information)?
This is POSIX XSI. Shouldn't there be some kind of gate? (Or since the entire
header is under XSI, no gate is needed since the user controls it on a file
level? I prefer this, but I don't know what general Newlib policy is, as most
are mixed in and need individual gates.)
(These comments are purely focused on the internal contents of the proposal, and
ignore the higher-level questions which have been under discussion about the
__hash_open() prototype, etc.)
Craig