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

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

```--
Lawrence Crowl
```

Received on 2013-10-18 01:28:09