bug-gnu-utils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Minor bug in gdbm-1.8.0


From: Paul_GreenVOS
Subject: Minor bug in gdbm-1.8.0
Date: Mon, 14 May 01 17:51 edt

Ooops.  I reported that gdbmopen.c does not declare ftruncate.
This is my mistake.  Once I set _POSIX_C_SOURCE up to a higher
level, the function was properly declared by unistd.h.  I
apologize for the error.

Thanks
PG
--
Paul Green                  | Mail: address@hidden
Senior Technical Consultant | Voice: +1 978-461-7557   FAX: +1 978-461-3610
Stratus Computer            | Video: PictureTel/AT&T by request.
Maynard, MA  01754          | Disclaimer: I speak for myself, not Stratus.

 
Date:           Sun, 13 May 01 19:31 edt
From:           address@hidden
To:             address@hidden, 
CC:             address@hidden
Subject:        Minor bug in gdbm-1.8.0

Gentle GDBM experts,

Thank you for providing such a clean package.  I was able to
port it to the POSIX.1 environment on the Stratus VOS operating
system without serious difficulty.  It compiles cleanly with GCC
2.95.2 and almost cleanly with the VOS Standard C compiler (our
own implementation of the ANSI C Standard).

Our own C compiler is quite strict in its default mode and so I
discovered that neither testgdbm.c nor testngdbm.c declares the
"exit" library routine.  Unlike some other C library routines,
exit is a subroutine, and so its default declaration as a
function leads to a linker warning on our implementation.  There
are other missing function declarations (see below) but at least
these are truly functions and I get only a trivial compiler
warning that I can easily suppress.  I have no way to suppress
the linker warning about the bad declaration.

It appears to me that this is a simple fix:  merely include the
stdlib.h header.  Here is a patch that takes care of this:

*** testdbm.c.orig      Tue May 18 20:16:07 1999
--- testdbm.c   Sat May 12 21:59:54 2001
***************
*** 31,36 ****
--- 31,39 ----
  #include "autoconf.h"
  
  #include <stdio.h>
+ #if HAVE_STDLIB_H
+ #include <stdlib.h>
+ #endif
  #include <sys/types.h>
  #if HAVE_SYS_FILE_H
  #include <sys/file.h>
*** testndbm.c.orig     Tue May 18 20:16:07 1999
--- testndbm.c  Sat May 12 22:01:13 2001
***************
*** 31,36 ****
--- 31,39 ----
  #include "autoconf.h"
  
  #include <stdio.h>
+ #if HAVE_STDLIB_H
+ #include <stdlib.h>
+ #endif
  #include <sys/types.h>
  #if HAVE_FILE_H
  #include <sys/file.h>

The other missing declarations are:

gdbmopen.c              missing ftruncate.
testdbm.c                       missing dbminit, strlen, store, delete.
testndbm.c              missing strlen.

I had one additional issue.  We do not use Unix-style library
files on VOS.  Instead, we create a file system directory that
holds all of the compiled object files, we add symbolic links in
this directory to list all of the external names and show which
file defines them, and our linker then searches a list of these
object file directories.  It confuses us greatly when someone
names a user object file as the same name as a C library
function, because we end up finding the user object file.  I
renamed two of the compiled object files to avoid this problem:

        dbmclose.obj    renamed to      dbm_close.obj
        close.obj               renamed to      dbmclose.obj

In both cases, the file name now agrees with the external name
that the file defines, and our linker is happy.

I hope you will consider making these changes in a future release.

Again, thanks for providing and for maintaining GNU GDBM.

Thanks
PG
--
Paul Green                  | Mail: address@hidden
Senior Technical Consultant | Voice: +1 978-461-7557   FAX: +1 978-461-3610
Stratus Computer            | Video: PictureTel/AT&T by request.
Maynard, MA  01754          | Disclaimer: I speak for myself, not Stratus.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]