Re: CVS update: samba/source/ubiqx

Robert Frank (frank@ifi.unibas.ch)
Tue, 12 May 1998 10:36:30 +0200

Date:	Tue, 12 May 1998 10:36:30 +0200
From:	Robert Frank <frank@ifi.unibas.ch>
Subject: Re: CVS update: samba/source/ubiqx
To:	samba-technical@samba.anu.edu.au

<nofill> > Let me go over this again...
>
> The reason that I object is that I think that the ubiqx modules, and
> parts of the "main" Samba code, should be able to stand alone. Mangle.c,
> for example, would be great as a stand-alone module. It should not depend
> upon the rest of the code to work. I'm also thinking about the smb.conf
> parsing and config database management in these terms. Make this *really*
> re-usable code.

I fully agree.

> So, with regard to the definition of NULL, I'd really rather re-solve the
> specific problem within the ubiqx code. These modules should work on just
> about any system anyway, so I have a real need to solve them.
>
> According to K&R 2ndEd., NULL should be defined in stdio.h (see pg. 102).
</nofill>

That's where I stop agreeing. I'd rather base all development on
posix/ansi than on K&R. Don't tell me that not all systems support/are
posix, I know that very well, as the NEXTSTEP/OPENSTEP platforms *aren't*
posix complient, but I nonetheless do all development conforming to posix,
where I have to 'map' the posix routines not found in BSD to the
appropriate BSD routines. Modern systems, such as Linux and Solaris, are
posix complient, and I'm sure that any newer unix will also be posix
complient. Sticking to posix gives everybody a common ground for
development and discussions. Using a platform dependent routine will
definitely cause trouble on many other platforms (even if its just because
of a slightly different implementaion), whiles posix/ansi is posix/ansi
and anything not acting according to the standard is simply broken (like
NeXT's versions ...). Many, many of today's systems have more or less
posix/ansi support (yea, even NeXT, you just have to know which of the
routines are broken).

That's whey I'd like to go posix. This also applies to the xx_mem_xx
stuff, if it isn't in posix/ansi, make sure you have an appropriate
posix/ansi workaround. Then others can easily figure out what to do if
their system neither supports the implemented non-posix routine nor the
posix routine.

> I happen to have a SunOS4 system handy, and NULL is defined there, so I

> think that the correct & simple solution would be to include that

> *instead of* <<stdlib.h>. I have also checked Amiga, Linux, and SGI

> systems and find that NULL is suitably defined.

Under Solaris, which is posix/ansi complient, NULL is defined in several
(9) places. According to the posix book I have (there are newer versions),
NULL is supposed to be officially defined in locale.h! Surprise: even
OPENSTEP has it defined there.

<nofill>
> Okay, so two options:
>
> 1) Remove includes.h and stdlib.h, replacing them with stdio.h
</nofill>

In posix, stdlib.h is the 'backwards compatible' library. It defines the
headers for functions which historically didn't require headers. So for
posix compliance, this should be left in ...

> 2) Remove includes.h, and put in:

> #include <<stdlib.h> /* Intended to get a define for NULL. */

> #ifndef NULL

> #include <<stdio.h> /* The correct way to get NULL defined, per K&R.

> #*/ endif

It's always good to have a last resort, so to have

#ifndef NULL

#define NULL 0 or NULL ((void *)0)

#endif

is a good idea.

-Robert

-------------------------------------

Institut fuer Informatik tel +41 (0)61 321 99 67

Universitaet Basel fax. +41 (0)61 321 99 15

Robert Frank

Mittlere Strasse 142 rfc822: frank@ifi.unibas.ch (NeXT,MIME mail ok)

CH-4056 Basel (remove any no_spam_ from my return address)

Switzerland