[v1] Port ndbm

Message ID 20190710085550.1106-1-vaibhavgupta40@gmail.com
State Accepted
Commit e50ad9fbdc5adfb5c13954a2798d1ea0ad53db34
Headers show
Series
  • [v1] Port ndbm
Related show

Commit Message

Vaibhav Gupta July 10, 2019, 8:55 a.m.
---
 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

-- 
2.21.0

Comments

Howland, Craig D. - US via newlib July 10, 2019, 4:44 p.m. | #1
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
Joel Sherrill July 10, 2019, 5:48 p.m. | #2
On Wed, Jul 10, 2019 at 11:44 AM Craig Howland via newlib <
newlib@sourceware.org> 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

>
Yaakov Selkowitz July 10, 2019, 5:59 p.m. | #3
On Wed, 2019-07-10 at 12:44 -0400, Craig Howland via newlib wrote:
> 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.)


The latter.

-- 
Yaakov Selkowitz
Senior Software Engineer - Platform Enablement
Red Hat, Inc.
Vaibhav Gupta July 10, 2019, 6:19 p.m. | #4
On Wed, Jul 10, 2019 at 10:14 PM Craig Howland via newlib <
newlib@sourceware.org> 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;

> > +

>

Hello,
As Joel mentioned, I ported this code from FreeBSD and haven't changed it.
I did some changes with `<db.h>` header and have mentioned about it, but
have
no idea why BSD have not used `size_t`. We can surely report to them about
it
if needed.

> >

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

>

Sure, but I would like to mention that __hash_open() prototype present in
hash.h in newlib
is old and doesn't even match with open group standards. I mailed a
proposal to update
search directory, on newlib mailing list.

> Craig

>
Joel Sherrill July 10, 2019, 6:30 p.m. | #5
On Wed, Jul 10, 2019 at 12:59 PM Yaakov Selkowitz <yselkowi@redhat.com>
wrote:

> On Wed, 2019-07-10 at 12:44 -0400, Craig Howland via newlib wrote:

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

>

> The latter.

>


Just to be clear, you are wanting gates around individual (or small groups
of) methods?

What about committing this with as few possible changes as possible to the
original
FreeBSD code and then doing this?

--joel

>

> --

> Yaakov Selkowitz

> Senior Software Engineer - Platform Enablement

> Red Hat, Inc.

>

>

>
Yaakov Selkowitz July 10, 2019, 6:45 p.m. | #6
On Wed, 2019-07-10 at 13:30 -0500, Joel Sherrill wrote:
> On Wed, Jul 10, 2019 at 12:59 PM Yaakov Selkowitz wrote:

> > On Wed, 2019-07-10 at 12:44 -0400, Craig Howland via newlib wrote:

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

> > 

> > The latter.

> 

> Just to be clear, you are wanting gates around individual (or small groups

> of) methods?


Gating is only necessary when some parts of a header are governed by
different standards than other parts therein (e.g. XSI or GNU
extensions to an ANSI header).  Gating is NOT necessary when an entire
header is governed by a later standard and not included by other
standard headers, as the #include itself is essentially the gate.

-- 
Yaakov Selkowitz
Senior Software Engineer - Platform Enablement
Red Hat, Inc.
Joel Sherrill July 10, 2019, 10:17 p.m. | #7
On Wed, Jul 10, 2019 at 1:45 PM Yaakov Selkowitz <yselkowi@redhat.com>
wrote:

> On Wed, 2019-07-10 at 13:30 -0500, Joel Sherrill wrote:

> > On Wed, Jul 10, 2019 at 12:59 PM Yaakov Selkowitz wrote:

> > > On Wed, 2019-07-10 at 12:44 -0400, Craig Howland via newlib wrote:

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

> > >

> > > The latter.

> >

> > Just to be clear, you are wanting gates around individual (or small

> groups

> > of) methods?

>

> Gating is only necessary when some parts of a header are governed by

> different standards than other parts therein (e.g. XSI or GNU

> extensions to an ANSI header).  Gating is NOT necessary when an entire

> header is governed by a later standard and not included by other

> standard headers, as the #include itself is essentially the gate.

>

>

Thanks. Have we missed any issues with this patch that need to be addressed?

Also when I regenerated with autoconf 2.69 instead of 2.68 from libc, there
were over 3K lines in the diff. The build worked but I assume someone who
regularly regenerates the files will want to do this.




> --

> Yaakov Selkowitz

> Senior Software Engineer - Platform Enablement

> Red Hat, Inc.

>

>

>
Vaibhav Gupta July 22, 2019, 4:10 p.m. | #8
On Thu, Jul 11, 2019 at 3:48 AM Joel Sherrill <joel@rtems.org> wrote:

> On Wed, Jul 10, 2019 at 1:45 PM Yaakov Selkowitz <yselkowi@redhat.com>

> wrote:

>

> > On Wed, 2019-07-10 at 13:30 -0500, Joel Sherrill wrote:

> > > On Wed, Jul 10, 2019 at 12:59 PM Yaakov Selkowitz wrote:

> > > > On Wed, 2019-07-10 at 12:44 -0400, Craig Howland via newlib wrote:

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

> > > >

> > > > The latter.

> > >

> > > Just to be clear, you are wanting gates around individual (or small

> > groups

> > > of) methods?

> >

> > Gating is only necessary when some parts of a header are governed by

> > different standards than other parts therein (e.g. XSI or GNU

> > extensions to an ANSI header).  Gating is NOT necessary when an entire

> > header is governed by a later standard and not included by other

> > standard headers, as the #include itself is essentially the gate.

> >

> >

> Thanks. Have we missed any issues with this patch that need to be

> addressed?

>

> Also when I regenerated with autoconf 2.69 instead of 2.68 from libc, there

> were over 3K lines in the diff. The build worked but I assume someone who

> regularly regenerates the files will want to do this.

>

Hello,
Are there any issues yet, left in this port? Can it be merged?

- Vaibhav Gupta


>

>

>

> > --

> > Yaakov Selkowitz

> > Senior Software Engineer - Platform Enablement

> > Red Hat, Inc.

> >

> >

> >

>
Joel Sherrill July 23, 2019, 3:22 p.m. | #9
Ping. Is it OK to merge this?

Thanks

--joel

On Mon, Jul 22, 2019 at 11:11 AM Vaibhav Gupta <vaibhavgupta40@gmail.com>
wrote:

>

>

> On Thu, Jul 11, 2019 at 3:48 AM Joel Sherrill <joel@rtems.org> wrote:

>

>> On Wed, Jul 10, 2019 at 1:45 PM Yaakov Selkowitz <yselkowi@redhat.com>

>> wrote:

>>

>> > On Wed, 2019-07-10 at 13:30 -0500, Joel Sherrill wrote:

>> > > On Wed, Jul 10, 2019 at 12:59 PM Yaakov Selkowitz wrote:

>> > > > On Wed, 2019-07-10 at 12:44 -0400, Craig Howland via newlib wrote:

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

>> > > >

>> > > > The latter.

>> > >

>> > > Just to be clear, you are wanting gates around individual (or small

>> > groups

>> > > of) methods?

>> >

>> > Gating is only necessary when some parts of a header are governed by

>> > different standards than other parts therein (e.g. XSI or GNU

>> > extensions to an ANSI header).  Gating is NOT necessary when an entire

>> > header is governed by a later standard and not included by other

>> > standard headers, as the #include itself is essentially the gate.

>> >

>> >

>> Thanks. Have we missed any issues with this patch that need to be

>> addressed?

>>

>> Also when I regenerated with autoconf 2.69 instead of 2.68 from libc,

>> there

>> were over 3K lines in the diff. The build worked but I assume someone who

>> regularly regenerates the files will want to do this.

>>

> Hello,

> Are there any issues yet, left in this port? Can it be merged?

>

> - Vaibhav Gupta

>

>

>>

>>

>>

>> > --

>> > Yaakov Selkowitz

>> > Senior Software Engineer - Platform Enablement

>> > Red Hat, Inc.

>> >

>> >

>> >

>>

>
Corinna Vinschen July 24, 2019, 7:22 a.m. | #10
On Jul 10 14:25, 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


Pushed.


Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat
Joel Sherrill July 24, 2019, 3:47 p.m. | #11
On Wed, Jul 24, 2019 at 2:23 AM Corinna Vinschen <vinschen@redhat.com>
wrote:

> On Jul 10 14:25, 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

>

> Pushed.

>


Thank you.

It touched a Makefile.am. Doesn't something need to be regenerated?

--joel

>

>

> Thanks,

> Corinna

>

> --

> Corinna Vinschen

> Cygwin Maintainer

> Red Hat

>
Corinna Vinschen July 24, 2019, 4:49 p.m. | #12
On Jul 24 10:47, Joel Sherrill wrote:
> On Wed, Jul 24, 2019 at 2:23 AM Corinna Vinschen <vinschen@redhat.com>

> wrote:

> 

> > On Jul 10 14:25, 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

> >

> > Pushed.

> >

> 

> Thank you.

> 

> It touched a Makefile.am. Doesn't something need to be regenerated?


Oh, right.  Done.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat
Corinna Vinschen July 24, 2019, 8:18 p.m. | #13
On Jul 24 09:22, Corinna Vinschen wrote:
> On Jul 10 14:25, 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

> 

> Pushed.


However, where's dbm_forder?  It's declared in ndbm.h but there's no
such function in ndbm.c.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat
Joel Sherrill July 24, 2019, 9:37 p.m. | #14
On Wed, Jul 24, 2019 at 3:18 PM Corinna Vinschen <vinschen@redhat.com>
wrote:

> On Jul 24 09:22, Corinna Vinschen wrote:

> > On Jul 10 14:25, 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

> >

> > Pushed.

>

> However, where's dbm_forder?  It's declared in ndbm.h but there's no

> such function in ndbm.c.

>


That's a darn good question. I just cloned the FreeBSD git repository and
the
only reference to it is in ndbm.h.

I did find some BSD 4.3 source online that had this method.

Should we remove it and file a FreeBSD bug?

--joel

>

>

> Corinna

>

> --

> Corinna Vinschen

> Cygwin Maintainer

> Red Hat

>
Vaibhav Gupta July 25, 2019, 5:37 a.m. | #15
On Thu, Jul 25, 2019, 1:48 AM Corinna Vinschen <vinschen@redhat.com> wrote:

> On Jul 24 09:22, Corinna Vinschen wrote:

> > On Jul 10 14:25, 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

> >

> > Pushed.

>

> However, where's dbm_forder?  It's declared in ndbm.h but there's no

> such function in ndbm.c.

>

Both dbm_forder and dbm_dirinfo are wrapped inside __BSD_VISIBLE, although
dbm_dirinfo is defined in ndbm.c but it will not be usable i guess.
.
I explored a bit, found that some features are for BSD systems and are not
compatible with POSIX,
Moreover dbm_forder and dbm_dirinfo are not mentioned in open group page.
.
I didn't planned to modify the contents much when i ported
It from FreeBSD and hence they are present here. If required I can remove
them and send a new patch.

Vaibhav Gupta

>

>

> Corinna

>

> --

> Corinna Vinschen

> Cygwin Maintainer

> Red Hat

>
Corinna Vinschen July 25, 2019, 8:56 a.m. | #16
On Jul 25 11:07, Vaibhav Gupta wrote:
> On Thu, Jul 25, 2019, 1:48 AM Corinna Vinschen <vinschen@redhat.com> wrote:

> 

> > On Jul 24 09:22, Corinna Vinschen wrote:

> > > On Jul 10 14:25, 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

> > >

> > > Pushed.

> >

> > However, where's dbm_forder?  It's declared in ndbm.h but there's no

> > such function in ndbm.c.

> >

> Both dbm_forder and dbm_dirinfo are wrapped inside __BSD_VISIBLE, although

> dbm_dirinfo is defined in ndbm.c but it will not be usable i guess.


Do you mean dbm_dirfno?  Why should it be unusable?

> I explored a bit, found that some features are for BSD systems and are not

> compatible with POSIX,

> Moreover dbm_forder and dbm_dirinfo are not mentioned in open group page.

> .

> I didn't planned to modify the contents much when i ported

> It from FreeBSD and hence they are present here. If required I can remove

> them and send a new patch.


Yes for dbm_forder, but dbm_dirfno doesn't look wrong, just BSDish,
which is fine when guarded.


Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat
Vaibhav Gupta July 25, 2019, 10:55 a.m. | #17
On Thu, Jul 25, 2019, 2:26 PM Corinna Vinschen <vinschen@redhat.com> wrote:

> On Jul 25 11:07, Vaibhav Gupta wrote:

> > On Thu, Jul 25, 2019, 1:48 AM Corinna Vinschen <vinschen@redhat.com>

> wrote:

> >

> > > On Jul 24 09:22, Corinna Vinschen wrote:

> > > > On Jul 10 14:25, 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

> > > >

> > > > Pushed.

> > >

> > > However, where's dbm_forder?  It's declared in ndbm.h but there's no

> > > such function in ndbm.c.

> > >

> > Both dbm_forder and dbm_dirinfo are wrapped inside __BSD_VISIBLE,

> although

> > dbm_dirinfo is defined in ndbm.c but it will not be usable i guess.

>

> Do you mean dbm_dirfno?  Why should it be unusable?

>

Yah sorry, dbm_dirfno(). By unusable i meant it will run on BSD systems.
Hence it won't create any problem for us.

>

> > I explored a bit, found that some features are for BSD systems and are

> not

> > compatible with POSIX,

> > Moreover dbm_forder and dbm_dirinfo are not mentioned in open group page.

> > .

> > I didn't planned to modify the contents much when i ported

> > It from FreeBSD and hence they are present here. If required I can remove

> > them and send a new patch.

>

> Yes for dbm_forder, but dbm_dirfno doesn't look wrong, just BSDish,

> which is fine when guarded.

>

Ok then i will remove the declaration of dbm_forder and send a new patch.

Vaibhav Gupta

>

>

> Thanks,

> Corinna

>

> --

> Corinna Vinschen

> Cygwin Maintainer

> Red Hat

>
Richard Earnshaw (lists) July 26, 2019, 9 a.m. | #18
On 24/07/2019 17:49, Corinna Vinschen wrote:
> On Jul 24 10:47, Joel Sherrill wrote:

>> On Wed, Jul 24, 2019 at 2:23 AM Corinna Vinschen <vinschen@redhat.com>

>> wrote:

>>

>>> On Jul 10 14:25, 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

>>>

>>> Pushed.

>>>

>>

>> Thank you.

>>

>> It touched a Makefile.am. Doesn't something need to be regenerated?

> 

> Oh, right.  Done.

> 

> 

> Corinna

> 


I'm now seeing a build error on arm-eabi (though interestingly, not 
AArch64):

/work/rearnsha/scratch/nightly/arm/trunk/./gcc/xgcc 
-B/work/rearnsha/scratch/nightly/arm/trunk/./gcc/ -nostdinc 
-B/work/rearnsha/scratch/nightly/arm/trunk/arm-eabi/thumb/newlib/ 
-isystem 
/work/rearnsha/scratch/nightly/arm/trunk/arm-eabi/thumb/newlib/targ-include 
-isystem 
/work/rearnsha/gnusrc/nightly/gcc-cross/trunk/newlib/libc/include 
-B/work/rearnsha/scratch/nightly/arm/trunk/arm-eabi/thumb/libgloss/arm 
-L/work/rearnsha/scratch/nightly/arm/trunk/arm-eabi/thumb/libgloss/libnosys 
-L/work/rearnsha/gnusrc/nightly/gcc-cross/trunk/libgloss/arm 
-B/work/rearnsha/scratch/nightly/arm/trunk/testinstall/arm-eabi/bin/ 
-B/work/rearnsha/scratch/nightly/arm/trunk/testinstall/arm-eabi/lib/ 
-isystem 
/work/rearnsha/scratch/nightly/arm/trunk/testinstall/arm-eabi/include 
-isystem 
/work/rearnsha/scratch/nightly/arm/trunk/testinstall/arm-eabi/sys-include 
-L/work/rearnsha/scratch/nightly/arm/trunk/./ld  -mthumb 
-DPACKAGE_NAME=\"newlib\" -DPACKAGE_TARNAME=\"newlib\" 
-DPACKAGE_VERSION=\"3.1.0\" -DPACKAGE_STRING=\"newlib\ 3.1.0\" 
-DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -I. 
-I/work/rearnsha/gnusrc/nightly/gcc-cross/trunk/newlib/libc/search 
-fno-builtin -D_COMPILING_NEWLIB -DARM_RDI_MONITOR -DHAVE_INIT_FINI 
-g -O2  -mthumb -c -o lib_a-ndbm.o `test -f 'ndbm.c' || echo 
'/work/rearnsha/gnusrc/nightly/gcc-cross/trunk/newlib/libc/search/'`ndbm.c
/work/rearnsha/gnusrc/nightly/gcc-cross/trunk/newlib/libc/search/ndbm.c: 
In function ‘dbm_open’:
/work/rearnsha/gnusrc/nightly/gcc-cross/trunk/newlib/libc/search/ndbm.c:67:12: 
error: ‘MAXPATHLEN’ undeclared (first use in this function)
    67 |  char path[MAXPATHLEN];
       |            ^~~~~~~~~~

Does this file need to include sys/param.h?
Vaibhav Gupta July 26, 2019, 9:09 a.m. | #19
On Fri, Jul 26, 2019, 2:31 PM Richard Earnshaw (lists) <
Richard.Earnshaw@arm.com> wrote:

>

>

> On 24/07/2019 17:49, Corinna Vinschen wrote:

> > On Jul 24 10:47, Joel Sherrill wrote:

> >> On Wed, Jul 24, 2019 at 2:23 AM Corinna Vinschen <vinschen@redhat.com>

> >> wrote:

> >>

> >>> On Jul 10 14:25, 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

> >>>

> >>> Pushed.

> >>>

> >>

> >> Thank you.

> >>

> >> It touched a Makefile.am. Doesn't something need to be regenerated?

> >

> > Oh, right.  Done.

> >

> >

> > Corinna

> >

>

> I'm now seeing a build error on arm-eabi (though interestingly, not

> AArch64):

>

> /work/rearnsha/scratch/nightly/arm/trunk/./gcc/xgcc

> -B/work/rearnsha/scratch/nightly/arm/trunk/./gcc/ -nostdinc

> -B/work/rearnsha/scratch/nightly/arm/trunk/arm-eabi/thumb/newlib/

> -isystem

> /work/rearnsha/scratch/nightly/arm/trunk/arm-eabi/thumb/newlib/targ-include

>

> -isystem

> /work/rearnsha/gnusrc/nightly/gcc-cross/trunk/newlib/libc/include

> -B/work/rearnsha/scratch/nightly/arm/trunk/arm-eabi/thumb/libgloss/arm

> -L/work/rearnsha/scratch/nightly/arm/trunk/arm-eabi/thumb/libgloss/libnosys

>

> -L/work/rearnsha/gnusrc/nightly/gcc-cross/trunk/libgloss/arm

> -B/work/rearnsha/scratch/nightly/arm/trunk/testinstall/arm-eabi/bin/

> -B/work/rearnsha/scratch/nightly/arm/trunk/testinstall/arm-eabi/lib/

> -isystem

> /work/rearnsha/scratch/nightly/arm/trunk/testinstall/arm-eabi/include

> -isystem

> /work/rearnsha/scratch/nightly/arm/trunk/testinstall/arm-eabi/sys-include

> -L/work/rearnsha/scratch/nightly/arm/trunk/./ld  -mthumb

> -DPACKAGE_NAME=\"newlib\" -DPACKAGE_TARNAME=\"newlib\"

> -DPACKAGE_VERSION=\"3.1.0\" -DPACKAGE_STRING=\"newlib\ 3.1.0\"

> -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -I.

> -I/work/rearnsha/gnusrc/nightly/gcc-cross/trunk/newlib/libc/search

> -fno-builtin -D_COMPILING_NEWLIB -DARM_RDI_MONITOR -DHAVE_INIT_FINI

> -g -O2  -mthumb -c -o lib_a-ndbm.o `test -f 'ndbm.c' || echo

> '/work/rearnsha/gnusrc/nightly/gcc-cross/trunk/newlib/libc/search/'`ndbm.c

> /work/rearnsha/gnusrc/nightly/gcc-cross/trunk/newlib/libc/search/ndbm.c:

> In function ‘dbm_open’:

> /work/rearnsha/gnusrc/nightly/gcc-cross/trunk/newlib/libc/search/ndbm.c:67:12:

>

> error: ‘MAXPATHLEN’ undeclared (first use in this function)

>     67 |  char path[MAXPATHLEN];

>        |            ^~~~~~~~~~

>

> Does this file need to include sys/param.h?

>

Yah. sys/param.h has the macro definition of MAXPATHLEN
.
I guess ndbm.c has included it.

Vaibhav Gupta

>

>
Richard Earnshaw (lists) July 26, 2019, 10:19 a.m. | #20
On 26/07/2019 10:09, Vaibhav Gupta wrote:
> On Fri, Jul 26, 2019, 2:31 PM Richard Earnshaw (lists) <

> Richard.Earnshaw@arm.com> wrote:

> 

>>

>>

>> On 24/07/2019 17:49, Corinna Vinschen wrote:

>>> On Jul 24 10:47, Joel Sherrill wrote:

>>>> On Wed, Jul 24, 2019 at 2:23 AM Corinna Vinschen <vinschen@redhat.com>

>>>> wrote:

>>>>

>>>>> On Jul 10 14:25, 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

>>>>>

>>>>> Pushed.

>>>>>

>>>>

>>>> Thank you.

>>>>

>>>> It touched a Makefile.am. Doesn't something need to be regenerated?

>>>

>>> Oh, right.  Done.

>>>

>>>

>>> Corinna

>>>

>>

>> I'm now seeing a build error on arm-eabi (though interestingly, not

>> AArch64):

>>

>> /work/rearnsha/scratch/nightly/arm/trunk/./gcc/xgcc

>> -B/work/rearnsha/scratch/nightly/arm/trunk/./gcc/ -nostdinc

>> -B/work/rearnsha/scratch/nightly/arm/trunk/arm-eabi/thumb/newlib/

>> -isystem

>> /work/rearnsha/scratch/nightly/arm/trunk/arm-eabi/thumb/newlib/targ-include

>>

>> -isystem

>> /work/rearnsha/gnusrc/nightly/gcc-cross/trunk/newlib/libc/include

>> -B/work/rearnsha/scratch/nightly/arm/trunk/arm-eabi/thumb/libgloss/arm

>> -L/work/rearnsha/scratch/nightly/arm/trunk/arm-eabi/thumb/libgloss/libnosys

>>

>> -L/work/rearnsha/gnusrc/nightly/gcc-cross/trunk/libgloss/arm

>> -B/work/rearnsha/scratch/nightly/arm/trunk/testinstall/arm-eabi/bin/

>> -B/work/rearnsha/scratch/nightly/arm/trunk/testinstall/arm-eabi/lib/

>> -isystem

>> /work/rearnsha/scratch/nightly/arm/trunk/testinstall/arm-eabi/include

>> -isystem

>> /work/rearnsha/scratch/nightly/arm/trunk/testinstall/arm-eabi/sys-include

>> -L/work/rearnsha/scratch/nightly/arm/trunk/./ld  -mthumb

>> -DPACKAGE_NAME=\"newlib\" -DPACKAGE_TARNAME=\"newlib\"

>> -DPACKAGE_VERSION=\"3.1.0\" -DPACKAGE_STRING=\"newlib\ 3.1.0\"

>> -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -I.

>> -I/work/rearnsha/gnusrc/nightly/gcc-cross/trunk/newlib/libc/search

>> -fno-builtin -D_COMPILING_NEWLIB -DARM_RDI_MONITOR -DHAVE_INIT_FINI

>> -g -O2  -mthumb -c -o lib_a-ndbm.o `test -f 'ndbm.c' || echo

>> '/work/rearnsha/gnusrc/nightly/gcc-cross/trunk/newlib/libc/search/'`ndbm.c

>> /work/rearnsha/gnusrc/nightly/gcc-cross/trunk/newlib/libc/search/ndbm.c:

>> In function ‘dbm_open’:

>> /work/rearnsha/gnusrc/nightly/gcc-cross/trunk/newlib/libc/search/ndbm.c:67:12:

>>

>> error: ‘MAXPATHLEN’ undeclared (first use in this function)

>>      67 |  char path[MAXPATHLEN];

>>         |            ^~~~~~~~~~

>>

>> Does this file need to include sys/param.h?

>>

> Yah. sys/param.h has the macro definition of MAXPATHLEN

> .

> I guess ndbm.c has included it.


Well, not included it.

R.
> 

> Vaibhav Gupta

> 

>>

>>
Vaibhav Gupta July 26, 2019, 10:33 a.m. | #21
On Fri, Jul 26, 2019, 3:49 PM Richard Earnshaw (lists) <
Richard.Earnshaw@arm.com> wrote:

>

>

> On 26/07/2019 10:09, Vaibhav Gupta wrote:

> > On Fri, Jul 26, 2019, 2:31 PM Richard Earnshaw (lists) <

> > Richard.Earnshaw@arm.com> wrote:

> >

> >>

> >>

> >> On 24/07/2019 17:49, Corinna Vinschen wrote:

> >>> On Jul 24 10:47, Joel Sherrill wrote:

> >>>> On Wed, Jul 24, 2019 at 2:23 AM Corinna Vinschen <vinschen@redhat.com

> >

> >>>> wrote:

> >>>>

> >>>>> On Jul 10 14:25, 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

> >>>>>

> >>>>> Pushed.

> >>>>>

> >>>>

> >>>> Thank you.

> >>>>

> >>>> It touched a Makefile.am. Doesn't something need to be regenerated?

> >>>

> >>> Oh, right.  Done.

> >>>

> >>>

> >>> Corinna

> >>>

> >>

> >> I'm now seeing a build error on arm-eabi (though interestingly, not

> >> AArch64):

> >>

> >> /work/rearnsha/scratch/nightly/arm/trunk/./gcc/xgcc

> >> -B/work/rearnsha/scratch/nightly/arm/trunk/./gcc/ -nostdinc

> >> -B/work/rearnsha/scratch/nightly/arm/trunk/arm-eabi/thumb/newlib/

> >> -isystem

> >>

> /work/rearnsha/scratch/nightly/arm/trunk/arm-eabi/thumb/newlib/targ-include

> >>

> >> -isystem

> >> /work/rearnsha/gnusrc/nightly/gcc-cross/trunk/newlib/libc/include

> >> -B/work/rearnsha/scratch/nightly/arm/trunk/arm-eabi/thumb/libgloss/arm

> >>

> -L/work/rearnsha/scratch/nightly/arm/trunk/arm-eabi/thumb/libgloss/libnosys

> >>

> >> -L/work/rearnsha/gnusrc/nightly/gcc-cross/trunk/libgloss/arm

> >> -B/work/rearnsha/scratch/nightly/arm/trunk/testinstall/arm-eabi/bin/

> >> -B/work/rearnsha/scratch/nightly/arm/trunk/testinstall/arm-eabi/lib/

> >> -isystem

> >> /work/rearnsha/scratch/nightly/arm/trunk/testinstall/arm-eabi/include

> >> -isystem

> >>

> /work/rearnsha/scratch/nightly/arm/trunk/testinstall/arm-eabi/sys-include

> >> -L/work/rearnsha/scratch/nightly/arm/trunk/./ld  -mthumb

> >> -DPACKAGE_NAME=\"newlib\" -DPACKAGE_TARNAME=\"newlib\"

> >> -DPACKAGE_VERSION=\"3.1.0\" -DPACKAGE_STRING=\"newlib\ 3.1.0\"

> >> -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -I.

> >> -I/work/rearnsha/gnusrc/nightly/gcc-cross/trunk/newlib/libc/search

> >> -fno-builtin -D_COMPILING_NEWLIB -DARM_RDI_MONITOR -DHAVE_INIT_FINI

> >> -g -O2  -mthumb -c -o lib_a-ndbm.o `test -f 'ndbm.c' || echo

> >>

> '/work/rearnsha/gnusrc/nightly/gcc-cross/trunk/newlib/libc/search/'`ndbm.c

> >> /work/rearnsha/gnusrc/nightly/gcc-cross/trunk/newlib/libc/search/ndbm.c:

> >> In function ‘dbm_open’:

> >>

> /work/rearnsha/gnusrc/nightly/gcc-cross/trunk/newlib/libc/search/ndbm.c:67:12:

> >>

> >> error: ‘MAXPATHLEN’ undeclared (first use in this function)

> >>      67 |  char path[MAXPATHLEN];

> >>         |            ^~~~~~~~~~

> >>

> >> Does this file need to include sys/param.h?

> >>

> > Yah. sys/param.h has the macro definition of MAXPATHLEN

> > .

> > I guess ndbm.c has included it.

>

> Well, not included it.

>

I checked my patch, ndbm.c is including sys/param.h
.
Or you mean that you have not included it?

Vaibhav Gupta

>

> R.

> >

> > Vaibhav Gupta

> >

> >>

> >>

>
Joel Sherrill July 26, 2019, 12:58 p.m. | #22
On Fri, Jul 26, 2019 at 5:34 AM Vaibhav Gupta <vaibhavgupta40@gmail.com>
wrote:

> On Fri, Jul 26, 2019, 3:49 PM Richard Earnshaw (lists) <

> Richard.Earnshaw@arm.com> wrote:

>

> >

> >

> > On 26/07/2019 10:09, Vaibhav Gupta wrote:

> > > On Fri, Jul 26, 2019, 2:31 PM Richard Earnshaw (lists) <

> > > Richard.Earnshaw@arm.com> wrote:

> > >

> > >>

> > >>

> > >> On 24/07/2019 17:49, Corinna Vinschen wrote:

> > >>> On Jul 24 10:47, Joel Sherrill wrote:

> > >>>> On Wed, Jul 24, 2019 at 2:23 AM Corinna Vinschen <

> vinschen@redhat.com

> > >

> > >>>> wrote:

> > >>>>

> > >>>>> On Jul 10 14:25, 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

> > >>>>>

> > >>>>> Pushed.

> > >>>>>

> > >>>>

> > >>>> Thank you.

> > >>>>

> > >>>> It touched a Makefile.am. Doesn't something need to be regenerated?

> > >>>

> > >>> Oh, right.  Done.

> > >>>

> > >>>

> > >>> Corinna

> > >>>

> > >>

> > >> I'm now seeing a build error on arm-eabi (though interestingly, not

> > >> AArch64):

> > >>

> > >> /work/rearnsha/scratch/nightly/arm/trunk/./gcc/xgcc

> > >> -B/work/rearnsha/scratch/nightly/arm/trunk/./gcc/ -nostdinc

> > >> -B/work/rearnsha/scratch/nightly/arm/trunk/arm-eabi/thumb/newlib/

> > >> -isystem

> > >>

> >

> /work/rearnsha/scratch/nightly/arm/trunk/arm-eabi/thumb/newlib/targ-include

> > >>

> > >> -isystem

> > >> /work/rearnsha/gnusrc/nightly/gcc-cross/trunk/newlib/libc/include

> > >> -B/work/rearnsha/scratch/nightly/arm/trunk/arm-eabi/thumb/libgloss/arm

> > >>

> >

> -L/work/rearnsha/scratch/nightly/arm/trunk/arm-eabi/thumb/libgloss/libnosys

> > >>

> > >> -L/work/rearnsha/gnusrc/nightly/gcc-cross/trunk/libgloss/arm

> > >> -B/work/rearnsha/scratch/nightly/arm/trunk/testinstall/arm-eabi/bin/

> > >> -B/work/rearnsha/scratch/nightly/arm/trunk/testinstall/arm-eabi/lib/

> > >> -isystem

> > >> /work/rearnsha/scratch/nightly/arm/trunk/testinstall/arm-eabi/include

> > >> -isystem

> > >>

> > /work/rearnsha/scratch/nightly/arm/trunk/testinstall/arm-eabi/sys-include

> > >> -L/work/rearnsha/scratch/nightly/arm/trunk/./ld  -mthumb

> > >> -DPACKAGE_NAME=\"newlib\" -DPACKAGE_TARNAME=\"newlib\"

> > >> -DPACKAGE_VERSION=\"3.1.0\" -DPACKAGE_STRING=\"newlib\ 3.1.0\"

> > >> -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -I.

> > >> -I/work/rearnsha/gnusrc/nightly/gcc-cross/trunk/newlib/libc/search

> > >> -fno-builtin -D_COMPILING_NEWLIB -DARM_RDI_MONITOR -DHAVE_INIT_FINI

> > >> -g -O2  -mthumb -c -o lib_a-ndbm.o `test -f 'ndbm.c' || echo

> > >>

> >

> '/work/rearnsha/gnusrc/nightly/gcc-cross/trunk/newlib/libc/search/'`ndbm.c

> > >>

> /work/rearnsha/gnusrc/nightly/gcc-cross/trunk/newlib/libc/search/ndbm.c:

> > >> In function ‘dbm_open’:

> > >>

> >

> /work/rearnsha/gnusrc/nightly/gcc-cross/trunk/newlib/libc/search/ndbm.c:67:12:

> > >>

> > >> error: ‘MAXPATHLEN’ undeclared (first use in this function)

> > >>      67 |  char path[MAXPATHLEN];

> > >>         |            ^~~~~~~~~~

> > >>

> > >> Does this file need to include sys/param.h?

> > >>

> > > Yah. sys/param.h has the macro definition of MAXPATHLEN

> > > .

> > > I guess ndbm.c has included it.

> >

> > Well, not included it.

> >

> I checked my patch, ndbm.c is including sys/param.h

> .

> Or you mean that you have not included it?

>


I think the issue is that there is an arm specific sys/param.h which does
not define MAXPATHLEN.

$ find . -name param.h | xargs -e grep MAXPATHLEN
./libc/include/sys/param.h:#define MAXPATHLEN PATH_MAX
./libc/sys/phoenix/sys/param.h:#define MAXPATHLEN       PATHSIZE
./libc/sys/rtems/include/sys/param.h: * MAXPATHLEN defines the longest
permissible path length after expanding
./libc/sys/rtems/include/sys/param.h:#define    MAXPATHLEN      PATH_MAX

$ find . -name param.h | grep sys/param
./libc/include/sys/param.h
./libc/sys/linux/sys/param.h
./libc/sys/phoenix/sys/param.h
./libc/sys/rtems/include/sys/param.h
./libc/sys/arm/sys/param.h

Based on those commands, I the file ./libc/sys/arm/sys/param.h is the
culprit. It is very minimal. It looks like a simple out of date copy of
libc/include/sys/param.h.

My proposed fix is to delete libc/include/sys/arm/param.h. Does that work
for you Richard?

--joel


>

> Vaibhav Gupta

>

> >

> > R.

> > >

> > > Vaibhav Gupta

> > >

> > >>

> > >>

> >

>
Richard Earnshaw (lists) July 26, 2019, 1:12 p.m. | #23
On 26/07/2019 13:58, Joel Sherrill wrote:
> On Fri, Jul 26, 2019 at 5:34 AM Vaibhav Gupta <vaibhavgupta40@gmail.com>

> wrote:

> 

>> On Fri, Jul 26, 2019, 3:49 PM Richard Earnshaw (lists) <

>> Richard.Earnshaw@arm.com> wrote:

>>

>>>

>>>

>>> On 26/07/2019 10:09, Vaibhav Gupta wrote:

>>>> On Fri, Jul 26, 2019, 2:31 PM Richard Earnshaw (lists) <

>>>> Richard.Earnshaw@arm.com> wrote:

>>>>

>>>>>

>>>>>

>>>>> On 24/07/2019 17:49, Corinna Vinschen wrote:

>>>>>> On Jul 24 10:47, Joel Sherrill wrote:

>>>>>>> On Wed, Jul 24, 2019 at 2:23 AM Corinna Vinschen <

>> vinschen@redhat.com

>>>>

>>>>>>> wrote:

>>>>>>>

>>>>>>>> On Jul 10 14:25, 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

>>>>>>>>

>>>>>>>> Pushed.

>>>>>>>>

>>>>>>>

>>>>>>> Thank you.

>>>>>>>

>>>>>>> It touched a Makefile.am. Doesn't something need to be regenerated?

>>>>>>

>>>>>> Oh, right.  Done.

>>>>>>

>>>>>>

>>>>>> Corinna

>>>>>>

>>>>>

>>>>> I'm now seeing a build error on arm-eabi (though interestingly, not

>>>>> AArch64):

>>>>>

>>>>> /work/rearnsha/scratch/nightly/arm/trunk/./gcc/xgcc

>>>>> -B/work/rearnsha/scratch/nightly/arm/trunk/./gcc/ -nostdinc

>>>>> -B/work/rearnsha/scratch/nightly/arm/trunk/arm-eabi/thumb/newlib/

>>>>> -isystem

>>>>>

>>>

>> /work/rearnsha/scratch/nightly/arm/trunk/arm-eabi/thumb/newlib/targ-include

>>>>>

>>>>> -isystem

>>>>> /work/rearnsha/gnusrc/nightly/gcc-cross/trunk/newlib/libc/include

>>>>> -B/work/rearnsha/scratch/nightly/arm/trunk/arm-eabi/thumb/libgloss/arm

>>>>>

>>>

>> -L/work/rearnsha/scratch/nightly/arm/trunk/arm-eabi/thumb/libgloss/libnosys

>>>>>

>>>>> -L/work/rearnsha/gnusrc/nightly/gcc-cross/trunk/libgloss/arm

>>>>> -B/work/rearnsha/scratch/nightly/arm/trunk/testinstall/arm-eabi/bin/

>>>>> -B/work/rearnsha/scratch/nightly/arm/trunk/testinstall/arm-eabi/lib/

>>>>> -isystem

>>>>> /work/rearnsha/scratch/nightly/arm/trunk/testinstall/arm-eabi/include

>>>>> -isystem

>>>>>

>>> /work/rearnsha/scratch/nightly/arm/trunk/testinstall/arm-eabi/sys-include

>>>>> -L/work/rearnsha/scratch/nightly/arm/trunk/./ld  -mthumb

>>>>> -DPACKAGE_NAME=\"newlib\" -DPACKAGE_TARNAME=\"newlib\"

>>>>> -DPACKAGE_VERSION=\"3.1.0\" -DPACKAGE_STRING=\"newlib\ 3.1.0\"

>>>>> -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -I.

>>>>> -I/work/rearnsha/gnusrc/nightly/gcc-cross/trunk/newlib/libc/search

>>>>> -fno-builtin -D_COMPILING_NEWLIB -DARM_RDI_MONITOR -DHAVE_INIT_FINI

>>>>> -g -O2  -mthumb -c -o lib_a-ndbm.o `test -f 'ndbm.c' || echo

>>>>>

>>>

>> '/work/rearnsha/gnusrc/nightly/gcc-cross/trunk/newlib/libc/search/'`ndbm.c

>>>>>

>> /work/rearnsha/gnusrc/nightly/gcc-cross/trunk/newlib/libc/search/ndbm.c:

>>>>> In function ‘dbm_open’:

>>>>>

>>>

>> /work/rearnsha/gnusrc/nightly/gcc-cross/trunk/newlib/libc/search/ndbm.c:67:12:

>>>>>

>>>>> error: ‘MAXPATHLEN’ undeclared (first use in this function)

>>>>>       67 |  char path[MAXPATHLEN];

>>>>>          |            ^~~~~~~~~~

>>>>>

>>>>> Does this file need to include sys/param.h?

>>>>>

>>>> Yah. sys/param.h has the macro definition of MAXPATHLEN

>>>> .

>>>> I guess ndbm.c has included it.

>>>

>>> Well, not included it.

>>>

>> I checked my patch, ndbm.c is including sys/param.h

>> .

>> Or you mean that you have not included it?

>>

> 

> I think the issue is that there is an arm specific sys/param.h which does

> not define MAXPATHLEN.

> 

> $ find . -name param.h | xargs -e grep MAXPATHLEN

> ./libc/include/sys/param.h:#define MAXPATHLEN PATH_MAX

> ./libc/sys/phoenix/sys/param.h:#define MAXPATHLEN       PATHSIZE

> ./libc/sys/rtems/include/sys/param.h: * MAXPATHLEN defines the longest

> permissible path length after expanding

> ./libc/sys/rtems/include/sys/param.h:#define    MAXPATHLEN      PATH_MAX

> 

> $ find . -name param.h | grep sys/param

> ./libc/include/sys/param.h

> ./libc/sys/linux/sys/param.h

> ./libc/sys/phoenix/sys/param.h

> ./libc/sys/rtems/include/sys/param.h

> ./libc/sys/arm/sys/param.h

> 

> Based on those commands, I the file ./libc/sys/arm/sys/param.h is the

> culprit. It is very minimal. It looks like a simple out of date copy of

> libc/include/sys/param.h.

> 

> My proposed fix is to delete libc/include/sys/arm/param.h. Does that work

> for you Richard?

> 


Or move some or all of it to machine/param.h, which is currently a 
placeholder.  Need to think about this a bit, but off to a meeting right 
now.

R.

> --joel

> 

> 

>>

>> Vaibhav Gupta

>>

>>>

>>> R.

>>>>

>>>> Vaibhav Gupta

>>>>

>>>>>

>>>>>

>>>

>>
Richard Earnshaw (lists) July 26, 2019, 3:26 p.m. | #24
Right, having reviewed the contents of the Arm version of sys/param.h, I 
agree that there's no point in keeping that version.  I've pushed the 
attached.

R.


On 26/07/2019 14:12, Richard Earnshaw (lists) wrote:
> 

> 

> On 26/07/2019 13:58, Joel Sherrill wrote:

>> On Fri, Jul 26, 2019 at 5:34 AM Vaibhav Gupta <vaibhavgupta40@gmail.com>

>> wrote:

>>

>>> On Fri, Jul 26, 2019, 3:49 PM Richard Earnshaw (lists) <

>>> Richard.Earnshaw@arm.com> wrote:

>>>

>>>>

>>>>

>>>> On 26/07/2019 10:09, Vaibhav Gupta wrote:

>>>>> On Fri, Jul 26, 2019, 2:31 PM Richard Earnshaw (lists) <

>>>>> Richard.Earnshaw@arm.com> wrote:

>>>>>

>>>>>>

>>>>>>

>>>>>> On 24/07/2019 17:49, Corinna Vinschen wrote:

>>>>>>> On Jul 24 10:47, Joel Sherrill wrote:

>>>>>>>> On Wed, Jul 24, 2019 at 2:23 AM Corinna Vinschen <

>>> vinschen@redhat.com

>>>>>

>>>>>>>> wrote:

>>>>>>>>

>>>>>>>>> On Jul 10 14:25, 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

>>>>>>>>>

>>>>>>>>> Pushed.

>>>>>>>>>

>>>>>>>>

>>>>>>>> Thank you.

>>>>>>>>

>>>>>>>> It touched a Makefile.am. Doesn't something need to be regenerated?

>>>>>>>

>>>>>>> Oh, right.  Done.

>>>>>>>

>>>>>>>

>>>>>>> Corinna

>>>>>>>

>>>>>>

>>>>>> I'm now seeing a build error on arm-eabi (though interestingly, not

>>>>>> AArch64):

>>>>>>

>>>>>> /work/rearnsha/scratch/nightly/arm/trunk/./gcc/xgcc

>>>>>> -B/work/rearnsha/scratch/nightly/arm/trunk/./gcc/ -nostdinc

>>>>>> -B/work/rearnsha/scratch/nightly/arm/trunk/arm-eabi/thumb/newlib/

>>>>>> -isystem

>>>>>>

>>>>

>>> /work/rearnsha/scratch/nightly/arm/trunk/arm-eabi/thumb/newlib/targ-include 

>>>

>>>>>>

>>>>>> -isystem

>>>>>> /work/rearnsha/gnusrc/nightly/gcc-cross/trunk/newlib/libc/include

>>>>>> -B/work/rearnsha/scratch/nightly/arm/trunk/arm-eabi/thumb/libgloss/arm 

>>>>>>

>>>>>>

>>>>

>>> -L/work/rearnsha/scratch/nightly/arm/trunk/arm-eabi/thumb/libgloss/libnosys 

>>>

>>>>>>

>>>>>> -L/work/rearnsha/gnusrc/nightly/gcc-cross/trunk/libgloss/arm

>>>>>> -B/work/rearnsha/scratch/nightly/arm/trunk/testinstall/arm-eabi/bin/

>>>>>> -B/work/rearnsha/scratch/nightly/arm/trunk/testinstall/arm-eabi/lib/

>>>>>> -isystem

>>>>>> /work/rearnsha/scratch/nightly/arm/trunk/testinstall/arm-eabi/include

>>>>>> -isystem

>>>>>>

>>>> /work/rearnsha/scratch/nightly/arm/trunk/testinstall/arm-eabi/sys-include 

>>>>

>>>>>> -L/work/rearnsha/scratch/nightly/arm/trunk/./ld  -mthumb

>>>>>> -DPACKAGE_NAME=\"newlib\" -DPACKAGE_TARNAME=\"newlib\"

>>>>>> -DPACKAGE_VERSION=\"3.1.0\" -DPACKAGE_STRING=\"newlib\ 3.1.0\"

>>>>>> -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -I.

>>>>>> -I/work/rearnsha/gnusrc/nightly/gcc-cross/trunk/newlib/libc/search

>>>>>> -fno-builtin -D_COMPILING_NEWLIB -DARM_RDI_MONITOR -DHAVE_INIT_FINI

>>>>>> -g -O2  -mthumb -c -o lib_a-ndbm.o `test -f 'ndbm.c' || echo

>>>>>>

>>>>

>>> '/work/rearnsha/gnusrc/nightly/gcc-cross/trunk/newlib/libc/search/'`ndbm.c 

>>>

>>>>>>

>>> /work/rearnsha/gnusrc/nightly/gcc-cross/trunk/newlib/libc/search/ndbm.c:

>>>>>> In function ‘dbm_open’:

>>>>>>

>>>>

>>> /work/rearnsha/gnusrc/nightly/gcc-cross/trunk/newlib/libc/search/ndbm.c:67:12: 

>>>

>>>>>>

>>>>>> error: ‘MAXPATHLEN’ undeclared (first use in this function)

>>>>>>       67 |  char path[MAXPATHLEN];

>>>>>>          |            ^~~~~~~~~~

>>>>>>

>>>>>> Does this file need to include sys/param.h?

>>>>>>

>>>>> Yah. sys/param.h has the macro definition of MAXPATHLEN

>>>>> .

>>>>> I guess ndbm.c has included it.

>>>>

>>>> Well, not included it.

>>>>

>>> I checked my patch, ndbm.c is including sys/param.h

>>> .

>>> Or you mean that you have not included it?

>>>

>>

>> I think the issue is that there is an arm specific sys/param.h which does

>> not define MAXPATHLEN.

>>

>> $ find . -name param.h | xargs -e grep MAXPATHLEN

>> ./libc/include/sys/param.h:#define MAXPATHLEN PATH_MAX

>> ./libc/sys/phoenix/sys/param.h:#define MAXPATHLEN       PATHSIZE

>> ./libc/sys/rtems/include/sys/param.h: * MAXPATHLEN defines the longest

>> permissible path length after expanding

>> ./libc/sys/rtems/include/sys/param.h:#define    MAXPATHLEN      PATH_MAX

>>

>> $ find . -name param.h | grep sys/param

>> ./libc/include/sys/param.h

>> ./libc/sys/linux/sys/param.h

>> ./libc/sys/phoenix/sys/param.h

>> ./libc/sys/rtems/include/sys/param.h

>> ./libc/sys/arm/sys/param.h

>>

>> Based on those commands, I the file ./libc/sys/arm/sys/param.h is the

>> culprit. It is very minimal. It looks like a simple out of date copy of

>> libc/include/sys/param.h.

>>

>> My proposed fix is to delete libc/include/sys/arm/param.h. Does that work

>> for you Richard?

>>

> 

> Or move some or all of it to machine/param.h, which is currently a 

> placeholder.  Need to think about this a bit, but off to a meeting right 

> now.

> 

> R.

> 

>> --joel

>>

>>

>>>

>>> Vaibhav Gupta

>>>

>>>>

>>>> R.

>>>>>

>>>>> Vaibhav Gupta

>>>>>

>>>>>>

>>>>>>

>>>>

>>>
From bfcd73e3fbf106e68871da9ceffcb3c4526ee3d2 Mon Sep 17 00:00:00 2001
From: Richard Earnshaw <Richard.Earnshaw@arm.com>

Date: Fri, 26 Jul 2019 16:08:55 +0100
Subject: [PATCH] [arm] remove libc/sys/arm/sys/param.h
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------2.17.1"

This is a multi-part message in MIME format.
--------------2.17.1
Content-Type: text/plain; charset=UTF-8; format=fixed
Content-Transfer-Encoding: 8bit


The Arm sys/param.h does not define anything differently to the
generic sys/param.h, but fails to define some things that that file
provides.  There does not appear to be any reason to keep this version
and we should revert to using the common version.
---
 newlib/libc/sys/arm/sys/param.h | 25 -------------------------
 1 file changed, 25 deletions(-)
 delete mode 100644 newlib/libc/sys/arm/sys/param.h


--------------2.17.1
Content-Type: text/x-patch; name="0001-arm-remove-libc-sys-arm-sys-param.h.patch"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment; filename="0001-arm-remove-libc-sys-arm-sys-param.h.patch"

diff --git a/newlib/libc/sys/arm/sys/param.h b/newlib/libc/sys/arm/sys/param.h
deleted file mode 100644
index 5b9464cca..000000000
--- a/newlib/libc/sys/arm/sys/param.h
+++ /dev/null
@@ -1,25 +0,0 @@
-/* ARM configuration file; HZ is 100 rather than the default 60 */
-
-#ifndef _SYS_PARAM_H
-# define _SYS_PARAM_H
-
-#include <machine/param.h>
-#include <machine/endian.h>
-
-#ifndef NBBY
-# define NBBY 8		/* number of bits in a byte */
-#endif
-#ifndef HZ
-# define HZ (60)
-#endif
-#ifndef NOFILE
-# define NOFILE (60)
-#endif
-#ifndef PATHSIZE
-# define PATHSIZE (1024)
-#endif
-
-#define MAX(a,b) ((a) > (b) ? (a) : (b))
-#define MIN(a,b) ((a) < (b) ? (a) : (b))
-
-#endif

--------------2.17.1--

Patch

diff --git a/newlib/libc/include/ndbm.h b/newlib/libc/include/ndbm.h
new file mode 100644
index 000000000..6c803702e
--- /dev/null
+++ b/newlib/libc/include/ndbm.h
@@ -0,0 +1,93 @@ 
+/*-
+ * SPDX-License-Identifier: BSD-3-Clause
+ *
+ * Copyright (c) 1990, 1993
+ *	The Regents of the University of California.  All rights reserved.
+ *
+ * This code is derived from software contributed to Berkeley by
+ * Margo Seltzer.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *    notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *    notice, this list of conditions and the following disclaimer in the
+ *    documentation and/or other materials provided with the distribution.
+ * 3. Neither the name of the University nor the names of its contributors
+ *    may be used to endorse or promote products derived from this software
+ *    without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ *
+ *	@(#)ndbm.h	8.1 (Berkeley) 6/2/93
+ * $FreeBSD$ : src/include/ndbm.h
+ *             Nov 20 19:45:28 2017 UTC by pfg
+ *             SVN Revision 326024
+ */
+
+#ifndef _NDBM_H_
+#define	_NDBM_H_
+
+/* #include <db.h> */
+
+/*
+ * The above header-file is directly included in `newlib/libc/search/ndbm.c`
+ * as `db.h` is present in form of `db_local.h`, inside `newlib/libc/search`
+ * directory and not in `newlib/libc/include`.
+ * Necessary data-types are mentioned in form of forward-declarations
+ */
+   
+/* Map dbm interface onto db(3). */
+#define DBM_RDONLY	O_RDONLY
+
+/* Flags to dbm_store(). */
+#define DBM_INSERT      0
+#define DBM_REPLACE     1
+
+/*
+ * The db(3) support for ndbm always appends this suffix to the
+ * file name to avoid overwriting the user's original database.
+ */
+#define	DBM_SUFFIX	".db"
+
+typedef struct {
+	void *dptr;
+	int dsize;	/* XXX Should be size_t according to 1003.1-2008. */
+} datum;
+
+struct __db;      /* Forward-declaration */
+typedef struct __db DB;   /* Forward-declaration */
+typedef DB DBM;
+#define	dbm_pagfno(a)	DBM_PAGFNO_NOT_AVAILABLE
+
+__BEGIN_DECLS
+int	 dbm_clearerr(DBM *);
+void	 dbm_close(DBM *);
+int	 dbm_delete(DBM *, datum);
+int	 dbm_error(DBM *);
+datum	 dbm_fetch(DBM *, datum);
+datum	 dbm_firstkey(DBM *);
+#if __BSD_VISIBLE
+long	 dbm_forder(DBM *, datum);
+#endif
+datum	 dbm_nextkey(DBM *);
+DBM	*dbm_open(const char *, int, mode_t);
+int	 dbm_store(DBM *, datum, datum, int);
+#if __BSD_VISIBLE
+int	 dbm_dirfno(DBM *);
+#endif
+__END_DECLS
+
+#endif /* !_NDBM_H_ */
diff --git a/newlib/libc/search/Makefile.am b/newlib/libc/search/Makefile.am
index 98920c3f4..a61107fb9 100644
--- a/newlib/libc/search/Makefile.am
+++ b/newlib/libc/search/Makefile.am
@@ -9,6 +9,7 @@  GENERAL_SOURCES = \
 	db_local.h \
 	extern.h \
 	hash.h \
+	ndbm.c \
 	page.h \
 	qsort.c
 
diff --git a/newlib/libc/search/ndbm.c b/newlib/libc/search/ndbm.c
new file mode 100644
index 000000000..7f3296078
--- /dev/null
+++ b/newlib/libc/search/ndbm.c
@@ -0,0 +1,217 @@ 
+/*-
+ * SPDX-License-Identifier: BSD-3-Clause
+ *
+ * Copyright (c) 1990, 1993
+ *	The Regents of the University of California.  All rights reserved.
+ *
+ * This code is derived from software contributed to Berkeley by
+ * Margo Seltzer.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *    notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *    notice, this list of conditions and the following disclaimer in the
+ *    documentation and/or other materials provided with the distribution.
+ * 3. Neither the name of the University nor the names of its contributors
+ *    may be used to endorse or promote products derived from this software
+ *    without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ */
+
+#if defined(LIBC_SCCS) && !defined(lint)
+static char sccsid[] = "@(#)ndbm.c	8.4 (Berkeley) 7/21/94";
+#endif /* LIBC_SCCS and not lint */
+#include <sys/cdefs.h>
+__FBSDID("$FreeBSD$ : src/lib/libc/db/hash/ndbm.c Nov 20 19:49:47 2017 UTC by pfg - SVN Revision 326025");
+
+/*
+ * This package provides a dbm compatible interface to the new hashing
+ * package described in db(3).
+ */
+
+#include <sys/param.h>
+
+#include <stdio.h>
+#include <string.h>
+#include <errno.h>
+
+#include <ndbm.h>
+#include "hash.h"
+
+#define __DBINTERFACE_PRIVATE        /* activate prototypes from db_local.h */
+#include "db_local.h"
+
+/*
+ * Returns:
+ * 	*DBM on success
+ *	 NULL on failure
+ */
+extern DBM *
+dbm_open(const char *file, int flags, mode_t mode)
+{
+	HASHINFO info;
+	char path[MAXPATHLEN];
+
+	info.bsize = 4096;
+	info.ffactor = 40;
+	info.nelem = 1;
+	info.cachesize = 0;
+	info.hash = NULL;
+	info.lorder = 0;
+
+	if( strlen(file) >= sizeof(path) - strlen(DBM_SUFFIX)) {
+		errno = ENAMETOOLONG;
+		return(NULL);
+	}
+	(void)strcpy(path, file);
+	(void)strcat(path, DBM_SUFFIX);
+	return ((DBM *)__hash_open(path, flags, mode, 0, &info));
+}
+
+extern void
+dbm_close(DBM *db)
+{
+	(void)(db->close)(db);
+}
+
+/*
+ * Returns:
+ *	DATUM on success
+ *	NULL on failure
+ */
+extern datum
+dbm_fetch(DBM *db, datum key)
+{
+	datum retdata;
+	int status;
+	DBT dbtkey, dbtretdata;
+
+	dbtkey.data = key.dptr;
+	dbtkey.size = key.dsize;
+	status = (db->get)(db, &dbtkey, &dbtretdata, 0);
+	if (status) {
+		dbtretdata.data = NULL;
+		dbtretdata.size = 0;
+	}
+	retdata.dptr = dbtretdata.data;
+	retdata.dsize = dbtretdata.size;
+	return (retdata);
+}
+
+/*
+ * Returns:
+ *	DATUM on success
+ *	NULL on failure
+ */
+extern datum
+dbm_firstkey(DBM *db)
+{
+	int status;
+	datum retkey;
+	DBT dbtretkey, dbtretdata;
+
+	status = (db->seq)(db, &dbtretkey, &dbtretdata, R_FIRST);
+	if (status)
+		dbtretkey.data = NULL;
+	retkey.dptr = dbtretkey.data;
+	retkey.dsize = dbtretkey.size;
+	return (retkey);
+}
+
+/*
+ * Returns:
+ *	DATUM on success
+ *	NULL on failure
+ */
+extern datum
+dbm_nextkey(DBM *db)
+{
+	int status;
+	datum retkey;
+	DBT dbtretkey, dbtretdata;
+
+	status = (db->seq)(db, &dbtretkey, &dbtretdata, R_NEXT);
+	if (status)
+		dbtretkey.data = NULL;
+	retkey.dptr = dbtretkey.data;
+	retkey.dsize = dbtretkey.size;
+	return (retkey);
+}
+
+/*
+ * Returns:
+ *	 0 on success
+ *	<0 failure
+ */
+extern int
+dbm_delete(DBM *db, datum key)
+{
+	int status;
+	DBT dbtkey;
+
+	dbtkey.data = key.dptr;
+	dbtkey.size = key.dsize;
+	status = (db->del)(db, &dbtkey, 0);
+	if (status)
+		return (-1);
+	else
+		return (0);
+}
+
+/*
+ * Returns:
+ *	 0 on success
+ *	<0 failure
+ *	 1 if DBM_INSERT and entry exists
+ */
+extern int
+dbm_store(DBM *db, datum key, datum data, int flags)
+{
+	DBT dbtkey, dbtdata;
+
+	dbtkey.data = key.dptr;
+	dbtkey.size = key.dsize;
+	dbtdata.data = data.dptr;
+	dbtdata.size = data.dsize;
+	return ((db->put)(db, &dbtkey, &dbtdata,
+	    (flags == DBM_INSERT) ? R_NOOVERWRITE : 0));
+}
+
+extern int
+dbm_error(DBM *db)
+{
+	HTAB *hp;
+
+	hp = (HTAB *)db->internal;
+	return (hp->error);
+}
+
+extern int
+dbm_clearerr(DBM *db)
+{
+	HTAB *hp;
+
+	hp = (HTAB *)db->internal;
+	hp->error = 0;
+	return (0);
+}
+
+extern int
+dbm_dirfno(DBM *db)
+{
+	return(((HTAB *)db->internal)->fp);
+}