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