On Wed, Jul 13, 2005 at 12:28:47AM +0200, Erik Trulsson wrote: > On Tue, Jul 12, 2005 at 03:08:54PM -0700, Joe Buck wrote: > > On Tue, Jul 12, 2005 at 11:42:23PM +0200, Erik Trulsson wrote: > > > Pointer subtraction is only well defined if both pointers point to > > > elements > > > in the same array (or one past the end of the array). Otherwise the > > > behaviour is undefined. > > > > While this is correct, there are certain cases that the standard leaves > > undefined but that nevertheless can be useful; for example, pointer > > subtraction can be used to estimate the amount of stack in use (of > > course, it is necessary to know if the stack grows upward or downward). > > > > Similarly, in an OS kernel, comparing pointers may make sense. > > Yes, there are some situations where it can be useful to compare pointers > to different objects, but then you need to make sure that the compiler you > use actually supports that.
No, you don't need to check. You are confusing standards legalese with industrial practice. You are currently running a computer that depends on such code (whether you run Unix, Linux, BSD, or Windows). In any case, the C standard together with the portable ABI standard that gcc and compatible compilers conform to suffice to guarantee that you can write code that will compare arbitrary pointers safely. Such code is, of course, non-portable, which means that it needs to be tested with each compiler and OS used. The only compilers where there is an issue with pointer comparison are the various memory models for 16-bit segmented architectures (e.g. 16-bit Windows), and even those compilers provide "huge pointers" because sometimes it is necessary to compare pointers beyond the guarantees made by the C standard.
