Let's define our own NULL

[William E. Davidsen Jr]

In article <160 at navtech.uucp> mark at navtech.uucp (Mark Stevans) writes:
| Back in the days when I was a contract C programmer, I once got into a
| disagreement over the advisability of the following idea:
| 
| 	"Let's define NULL in our product-wide header file like so:
| 
| 		#ifndef NULL
| 		#define NULL	0
| 		#endif
| 
| 	That way, if someone needs NULL but doesn't need to use the standard
| 	I/O library, he won't need to pull in <stdio.h>."

  I know I'll get flamed for disagreeing with K&R, but this is WRONG.
The original book was written before segmented archetectures were
commonly used, and the idea of "near" and "far" pointers was not an
issue. When defining NULL as zero, you open the possibility of errors in
argument lists terminating with NULL, since *only* assignment will
translate zero to a pointer. Look at the exec family to see where NULL
is passed where a pointer is expected.

  Better is to define NULL:
	#define NULL	((void *) 0)
and be sure it works. Some compilers have all sorts of tests to use zero
or zero long, but this always leaves room for a problem in mixed mode
programming.

  Obviously there are ill-written programs which expect NULL to be an
int, even though the term "NULL pointer" is used in K&R, even in the
index. These programs may break in some obscure ways when a true pointer
is used, so my solution is not perfect.

  For all the people who are going to post saying "ignore the
brain-damaged PC," stay in school. People who write software for a
living can't ignore ten million possible sales, or the ability to run on
really cheap units inhouse. Anyone who lives in that commercial
environment must live with it, and anyone who wants to write postable
code in general should consider all current and future targets.

  Okay, I linked my mail file to the asbestos disk, let's hear from you.

-- 
	bill davidsen		(wedu at ge-crd.arpa)
  {uunet | philabs | seismo}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -me