how has C bitten you? (Really,
Guy Harris
guy at sun.uucp
Wed Sep 4 16:03:40 AEST 1985
> One final, subtle, point. K&R does not guarantee that the *value* 0
> is distinguishable from all other pointers, but rather, that the
> *constant* 0 is. That is to say, you may compare against 0 to
> determine the validity of a pointer (or assign to guarantee
> invalidity), but you may not assume that comparison against (or
> assignment of) an int variable whose value is 0 will have the same
> result.
>
> I don't see why the restriction applies to non-pointer variables. As long
> as type coercions are explicit, this should apply to all values of zero,
> whether encountered as a literal in the program or as the value of a
> variable of integral type.
("Oh no, Mabel! Here comes another K&R quote!")
7.7 Equality operators
A pointer may be compared to an integer, but the result is
machine independent unless the integer is *the constant* 0.
(Italics mine)
7.13 Conditional operator
...otherwise, one must be a pointer and the other *the constant*
0, and the result has the type of the pointer. (Italics mine)
7.14 Assignment operators
...However, it is guaranteed that assignment of *the constant*
0 to a pointer will produce a null pointer distinguishable
from a pointer to any object. (Italics mine)
I'd say the intent of K and R was pretty clear here, wouldn't you?
As for "why" - think of a machine where a null pointer *didn't* have the
same bit pattern as the integer 0. Every time you assigned an integer to a
pointer, you'd have to check whether the integer was zero or not and assign
a null pointer instead (unless the computation you had to do to convert an
integer to a pointer did this anyway). Why penalize those assignments
solely to make assigning a 0 other than a constant 0 set the pointer to a
null pointer?
Guy Harris
More information about the Comp.lang.c
mailing list