pointer comparisons in dpANS C

[Karl Heuer]

In article <14061 at mimsy.UUCP> chris at mimsy.UUCP (Chris Torek) writes:
>In article <8696 at smoke.ARPA> gwyn at smoke.ARPA (Doug Gwyn) writes:
>>The key is that you are allowed to portably compare pointers only in two
>>cases:  at least one pointer is a null pointer, or both pointers are
>>pointers into the same object.  This means that the fact that p1==p2 for
>>pointers to distinct objects is not a problem, since such comparison is
>>"undefined". ...
>
>This point (which is true) makes me wonder about something.  ...

I have to disagree with both of you.  As I interpret the rules, the relational
operators (<, etc) require that the operands belong to the same aggregate, but
the equality operators (==, !=) can be applied to any valid pointers.  (This
may imply, for certain architectures, that comparing pointers for equality is
harder than comparing integers.)

Unfortunately I can't find a definitive statement in the dpANS or Rationale
that supports my interpretation, and the line about the equality operators
being analogous to relationals argues against it.  But surely this wasn't the
intent of the Committee; it invalidates too much working code!

>Every address returned by malloc must compare as not distinct from
>every other address, lest this routine delete the wrong object.

"If two pointers ... compare equal, they point to the same object."  Of course
this is irrelevant if the analogy to relational operators is upheld.

Karl W. Z. Heuer (ima!haddock!karl or karl at haddock.isc.com), The Walking Lint
(Chris, when you change the subject line, please leave a `was:' remnant so the
newsreaders can track it.)