if (p), where p is a pointer - PLEASE READ

Guy Harris guy at sun.uucp
Sat Oct 5 16:53:59 AEST 1985

> If you are really insistant, you can even access address location 0
> in memory on some machines since many segmented systems like to
> have the first byte of executable code.

You may consider this a bug, or you may consider it a feature, but

	char *p = 0;

is not guaranteed to assign a value to "p" which will point at address
location 0.

	char *p = 4;

is more likely to assign a value to "p" that will point at address location
4 than the original construct is to assign a value pointing at 0.  Assigning
a constant 0 to a pointer is treated differently from assigning any other
value to a pointer.

> The important thing here is that you are not explicitly required to CAST
> a NULL for fear of loss of significant bits, sign extension, or similar
> problems associated with cross-type comparisons (like comparing 0126 <
> '\240') which require explicit casting.

You are not required to cast a NULL in comparisons because the language
specifies that a 0 (or NULL) is to be converted to a null pointer of the
appropriate type in a comparison.  It does not, however, specify that such
conversions are done in function calls, so you *are* required to cast NULL
when it is used as an argument to a function.

> A popular convention is to use the "(char *)0" definition.  This can
> get confusing if your source code contains (int *)NULL.  Some (the
> bad ones) versions of lint give interesting results.

All versions of "lint" that I know of complain when you say something like

	(int *)(char *)0;

since you're casting a pointer of one type to a pointer of another type
which is, in general, dangerous.  In this particular case it's probably
safe; however, there's no reason to have code of that type in the first
place (see many articles explaining why defining NULL as "(char *)0" is
totally wrong).

	Guy Harris

More information about the Comp.lang.c mailing list