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

From: Lawrence Crowl <Lawrence_at_[hidden]>
Date: Thu, 17 Oct 2013 16:12:39 -0700
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.

```--
Lawrence Crowl
```