Re: [PATCH v1] Port ndbm

On Wed, Jul 10, 2019 at 11:44 AM Craig Howland via newlib <
[email protected]> wrote:

> 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;
>

This code is exactly from FreeBSD so I am hesitant to change it here.

Would filing a bug against FreeBSD be the right path?


> > +
> >
> What about documentation (i.e. man page information)?
>

How is this introduced in a case like this? Newlib normally puts some
markup at the
top of a file. We don't want to modify the files copied from FreeBSD any
more than
absolutely necessary.

Would it work to add an ndbm_docs.c which had nothing in it but
documentation?


> 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.)
>

I have no idea on this one. If we have to wrap it in an __XSI_VISIBLE
conditional,
then the source code will need to define that I think before including at
least this .h
file.

Should it just be an ifdef for __XSI_VISIBLE or a specific level?


> (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.)
>

I don't remember if I I waded in on that topic on the newlib list but my
advice to
Vaibhav was to try to get things as close as possible to the current
FreeBSD source.

Do you think that's a good rule?

--joel


> Craig
>