ints vs. pointers

[Kevin Martin]

>I can remain silent no longer.  In the debate about NULL vs non-NULL,
>people seem to be overlooking the fact that the number of actual "data"
>bits (as opposed to "noise" bits such as object size, etc., used on
>some CPUs) in a pointer MUST BE no bigger than the number of bits in an int!
>[Before the flames start I KNOW K&R's not a standard but it's the closest
>we've got.]  I refer you to Appendix A, para 7.4 (page 189 in my edition):
>
>	If two pointers of the same type are subtracted, the result is con-
>	verted (by division by the length of the object) to an int representing
>	the number of objects separating the pointed-to objects.
>
>This is clearly not necessarily possible if you have (say) 32-bit pointers
>(with ALL 32 bits being address) and 16-bit ints.
>John Mackin, Physiology Department, University of Sydney, Sydney, Australia

It isn't possible with 32 bit ints either. You need 33 bit ints, since
the pointers can be as much as 2^32-1 away from each other in either direction.

Making ints twice as long for just this consideration is a waste. I hope that
the new standard says that the result is an implementation-dependant
integral type.
 
Also, consider pointers on a segmentted architecture: There are 'n' bits
of significance (including the segment number), but since k&r elsewhere
forbids subtracting or comparing pointers which don't point to the same array
(i.e. don't have the same segment number), the resulting difference can fit
in substantially fewer than 'n' bits.

All that limiting the size of a pointer difference does is limit the size
(in units of sizeof(type)) of an array of (type).
              Kevin Martin, UofW Software Development Group