Subject: Re: NULL return value checking
To: None <firstname.lastname@example.org>
From: Greg A. Woods <email@example.com>
Date: 04/24/2002 14:17:53
[ On Wednesday, April 24, 2002 at 18:36:33 (+0100), David Laight wrote: ]
> Subject: Re: NULL return value checking
> I don't use NULL, not ever! I use 'if (pointer)', 'if (!pointer)' and
> 'pointer = 0'.
Me too! ;-) Thouh I usually use 'pointer = NULL' and 'return NULL;'.
> All the above are completely portable, and always valid C.
And still with NULL in assignment and return, even with "broken" [:-)]
compilers that do not "#define NULL 0".....
> (I also have a habit of assuming that the null pointer as the zero
> bit pattern because I will use memset, bzero and calloc to set
> pointers to null.
I've long been under the impression that the very reason for the
invention of calloc() was to ensure that any pointers in the allocated
storage would initially be null pointers (and also of course such that
any character arrays in the allocated array would be filled with all
NUL, i.e. '\0', characters).
Also the BSS segment in unix exec images is zeroed to contain all binary
zero values for the same purpose (i.e. so that the compiler doesn't have
to include runtime code that explicitly initializes uninitialized
variables to zero, including pointers).
I think any C implementer would be risking insanity to hope to use a non
zero internal representation of a null pointer; and any computer
designer expecting C to run on hardware that had non-zero null pointers
would similarly risk a riot at best! ;-) I don't think a unix port to
such a machine would be a very efficient affair....
One final note: even lisp "nil" pointers are generally interally
represented as all zero bits, at least with the lisp interpreters I'm
familiar with on unix systems, but they're often not as wide as the word
they're stored in -- other bits are packed in there too, often confusing
naive programmers into thinking lisp nil pointers have a non-zero
representation (they just forgot to mask off the non-pointer bits).
Greg A. Woods
+1 416 218-0098; <firstname.lastname@example.org>; <email@example.com>; <firstname.lastname@example.org>
Planix, Inc. <email@example.com>; VE3TCP; Secrets of the Weird <firstname.lastname@example.org>