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