From: Rob McCool <robm@netscape.com>
Newsgroups: netscape.devs-nsapi
Subject: Re: NSAPI and NDBM
Date: Wed, 23 Oct 1996 18:29:22 -0700

There really isn't a whole lot I can tell you. The DBM library
definitions were a mistake. The memory allocation routines and select
were overridden to make them thread safe. As future versions move away
from our home-grown threading implementation, these collisions will
disappear. 

--Rob


Ian Paul Foot wrote:
> We are using CGI programs which set up a cookie database using NDBM.
> Our NSAPI programs to process these cookies works perfectly with the
> Netscape Communications Server, but not with the Enterprise or
> Fasttrack servers.  Using 'odump -Dc' (on Dec Unix) gives the
> following list of conflicts between ns-httpd and the standard C
> library:
> 
> hcreate         trunc           ceil            floor
> copysign        mktemp          dbm_nextkey     dbm_firstkey
> dbm_store       dbm_delete      dbm_fetch       fabs
> dbm_open        dbm_close       cfree           strerror
> modf            frexp           ldexp           rint
> mkstemp         hsearch         hdestroy        free
> realloc         select          malloc          calloc
> 
> If you are providing an API for C programmers, then IMO
> it is a very bad idea to start redefining standard library
> functions.  If my NSAPI programs for the Communications
> server do not work with Enterprise then what guarantee do I
> have that you will not redefine more stdlib functions in
> future releases and that more of my NSAPI programs will
> cease to work.  The who point of having a standard library
> is that it is standard - the functions should work in a
> well-defined manner.  Redefining them to suit yourself
> is a very bad practise as programmers writing NSAPI
> programs rely on the standard C library working correctly.
> 
> Your suggestion of linking with a static libdbm.a
> does not work on Dec Alpha, as it simply calls the
> dynamic functions in libc.so, which you have redefined.
> 
> It can be made to work on Dec Alpha by either:
> 
> Linking libc.a statically and then creating the shared
> library using:
> 
>         ld -r ${OBJS} -lc -o temp.o
>         ld -shared -all -expect_unresolved "*" temp.o -o sharedlib.so
> 
> or using ar to extract ndbm.o from libc.a and then using:
> 
>         ld -r ${OBJS} ndbm.o -o temp.o
>         ld -shared -all -expect_unresolved "*" temp.o -o sharedlib.so
> 
> However, whilst this works on Dec Unix, it does not work on Solaris.
> I need a simple solution than will work on both Dec and Sun.
> Dec do not provide the Berkeley database library (I haven't checked
> whether Sun do) but downloading then libraries, compiling them,
> installing them on all of our servers, linking BDBM into perl and
> modifying all of our CGI programs is not a satisfactory solution.
> 
> I would strongly advise developers not to use NSAPI if possible
> as there is no guarantee that you will not break more standard
> library functions in further releases and cause them the sort
> of headaches and many wasted days that this has caused me.  I no
> longer have any confidence in the Netscape servers and NSAPI.
> 
> Ian Paul Foot
> Technical Products Group - Web Products
> Reuters
> 68-74 Carter Lane
> London, ENGLAND
> 
> http://www.reuters.com

--
Rob McCool, robm@netscape.com http://home.netscape.com/people/robm/
Stunt Programmer, Netscape Communications Corporation
It was working ten minutes ago, I swear...

Reproduced by permission of the author.