# Re: [ub] Justification for < not being a total order on pointers?

From: Gabriel Dos Reis <gdr_at_[hidden]>
Date: Thu, 17 Oct 2013 19:18:13 -0500
Lawrence Crowl <Lawrence_at_[hidden]> writes:

| On 10/17/13, Gabriel Dos Reis <gdr_at_[hidden]> wrote:
| > Lawrence Crowl <Lawrence_at_[hidden]> writes:
| >
| > | On 10/17/13, James Dennett <jdennett_at_[hidden]> wrote:
| > | > On Oct 17, 2013, Gabriel Dos Reis <gdr_at_[hidden]> wrote:
| > | > > James Dennett <jdennett_at_[hidden]> writes:
| > | > > > I think it's not useful though; nothing guarantees that
| > | > > > p == q => intptr_t(p) == intptr_t(q), so far as I know,
| > | > >
| > | > > How do you arrive to this conclusion?
| > | >
| > | > As always, it's hard to point to where something is _not_
| > | > specified.
| > | >
| > | > I'm aware of no such guarantee. If you're aware of one, you
| > | > can presumably cite it, and I'd appreciate such a citation.
| > | > All I see is "A pointer can be explicitly converted to any
| > | > integral type large enough to hold it. The mapping function is
| > | > implementation-defined." We can debate whether the word
| > | > "function" there should be taken in a pure mathematical sense,
| > | > and whether "a pointer" means the value rather than the
| > | > representation, and if we have just the right reading (it's a
| > | > function on pointer values) then we get that equal pointers
| > | > have equal values when converted to intptr_t. We don't have
| > | > any guarantee about whether it's an order-preserving function
| > | > though, unless that's somewhere else.
| > |
| > | As an example, consider 8086 segmented pointers A:B and C:D that
| > | point to the same object. If the intptr_t conversion consistes
| > | of concatentationg A and B into a 32-bit value, the implication
| > | above is broken. To preserve the implication, the implementation
| > | would need to split and shift A and then do some carry adds,
| > | which is much more expensive than the simple concatenation.
| >
| > Let's postulate that segmented architecture do not exist anymore; where
| > are we in terms of the implication?
|
| I guess that depends on whether we have an implementation that puts
| an address of size n into a word of size m>n and does not zero/sign
| extend the result. I do not know of such an implementation.

The implication in question is this:

p == q => intptr_t(p) == intptr_t(q)

where p and q are pointers. I am having trouble following how, even on
such exotic architecture, the implication will be affected.

I suppose the other implication that is on the mind of many people but
not being discussed is

p != q => intptr_t(p) != intptr_t(q)

-- Gaby