Pointer comparison and Portability

[faustus at ucbcad.UUCP]

In article <4537 at brl-adm.ARPA>, Schauble at mit-multics.arpa (Paul Schauble) writes:
> Unfortunately, the Intel 8086 series provides another counter example.
> On this machine, address are in the form of segment and offset.  The
> Actual Address is 16*segment + offset.  This is usually written as
> segment:offset.  Thus, the two pointers 0100:0010 and 0101:0000 point at
> the same byte.  If compared, they will *NOT* compare equal.

I think they will have to compare equal.  If the compiler generates
naive code to compare them it's wrong.  Just as "!p" MUST be true
after a "p = 0", where p is a char * and the machine uses a NULL pointer
that isn't an all-zero bit pattern, "p == q" MUST be true if they
point at the same address, no matter what they look like internally.

> Seems like when K & R says that pointer comparison is undefined except
> when the two are pointers to the same array, it should be taken to mean
> exactly that for all operators, including == and !=.

I think you want to re-phrase this.  If this were literally true then
"p = q; if (p == q) ..." would have undefined semantics.

This is sort of a moot point anyway, since presumably there is no way that
you could get a "de-normalized" pointer within C without using backdoor
casting of values...  But you're just asking for trouble if you ignore the
possibility.

	Wayne