Pointer comparison and Portability

[guy at gorodish.UUCP]

>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.

Yes, but *if* you happen to construct two different long pointers that
point to the same address, that's just like double-mapping a location
with an MMU.

>So, if two pointers compare equal, they definately point at the same
>object.  However, the converse is not true.  Two pointers that do not
>compare equal do NOT (necessarily) point at different objects.

Yes, but this is an escape hatch for the benefit of e.g. systems
that have to do double mapping.  It is *not* intended to render
comparison of pointers for equality useless except when comparing
pointers to elements in the same array.

>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 !=.

Yes, but the ANSI C standard explicitly separates pointer comparison
for (in)equality from relational comparison on pointers.  Anybody who
tried to sell *me* a C implementation where the same object had two
addresses *except* when something was explicitly doubly mapped, or in
similarly unusual cases (e.g. an 808[68] with no memory mapping,
where a segment, treated as a full 64KB segment, overlapped another
segment, but where the segment *really* isn't long enough to overlap
it) - i.e., an implementation where pointer equality wasn't
equivalent to object equality, except in some *very* specialized and
*explicitly*-documented cases - would be shown the door rather
quickly.