Pointer comparison and Portability
faustus at ucbcad.UUCP
faustus at ucbcad.UUCP
Wed Feb 25 08:53:03 AEST 1987
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
More information about the Comp.lang.c
mailing list