64bit NULL?

[Erik Trulsson]

On Mon, Oct 27, 2003 at 02:49:51PM +0100, Harti Brandt wrote:
> 
> Hi all,
> 
> a question came up wether the NULL should be defined as (0L) on sparc.
> (Solaris does this). Currently we define NULL as 0. This may cause

Both are perfectly good definitions of NULL.
All correct programs must be able to handle either definition as well
as being able to handle NULL being defined as ((void*)0) which is also
a correct and fairly popular way of defining NULL (although it is not
a valid definition in C++.)

> problems for function with variable argument lists that expect a
> terminating NULL pointer. A prominent example is execl(). Although POSIX

Only for buggy invocations of such functions.

> (and our man page) gives the synopsis
> 
> 	execl(...., (char *)0)

Looks correct.

> 
> our man pages says that the list must be terminated by a NULL pointer,
> POSIX speaks 'null pointer'.

Correct.

>  According to ISO-C NULL is a symbol that
> defines a null pointer so that:

Wrong.  ISO C defines NULL as 'null pointer constant'.  This is not the
same thing as a null pointer.

>From n869.txt (a draft version of the C99 standard)

       6.3.2.3  Pointers

       ....

       [#3]  An  integer  constant  expression with the value 0, or
       such an expression cast to type void *,  is  called  a  null
       pointer  constant.48)   If  a  null  pointer   constant   is |
       converted to a pointer type, the resulting pointer, called a
       null pointer, is guaranteed to compare unequal to a  pointer
       to any object or function.

       ....

       48)The macro NULL is defined in <stddef.h> as a null pointer
          constant; see 7.17.


> 
> 	execl(..., NULL)
> 
> appears to be legal, yet will probably cause failure on FreeBSD-sparc64.

But is is not legal.  If you pass NULL as an argument to a function
with variable arguments, or to a function that does not have a
prototype in scope (in neither case does the compiler know what type
the argument should have, so it won't convert it for you) you must
convert NULL to the correct pointer type.

> Shouldn't we change our NULL definition to
> 
> #define	NULL	(0L)

No good reason to.

> 
> ? What would break by this change?

It would hide some bugs in programs that (incorrectly) assume that NULL
can be used in any place that a null pointer is needed.
Hiding bugs is rarely a good thing, since the bugs are less likely to
be fixed then.
It would of course also break the same buggy programs if used on a
system where long does not have the same size or representation as a
pointer.


-- 
<Insert your favourite quote here.>
Erik Trulsson
ertr1013 at student.uu.se