|From:||Erik Trulsson (ertr...@student.uu.se)|
|Date:||Oct 27, 2003 6:33:35 am|
On Mon, Oct 27, 2003 at 02:49:51PM +0100, Harti Brandt wrote:
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)
our man pages says that the list must be terminated by a NULL pointer, POSIX speaks 'null pointer'.
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)
[#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.
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 ertr...@student.uu.se