C++ Logo

sg12

Advanced search

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

From: Gabriel Dos Reis <gdr_at_[hidden]>
Date: Thu, 17 Oct 2013 23:13:15 -0500
Nevin Liber <nevin_at_[hidden]> writes:

| On 17 October 2013 19:18, Gabriel Dos Reis <gdr_at_[hidden]> wrote:
|
|
| 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 can imagine that on a system concerned with security where sizeof(intptr_t) >
| sizeof(p) random salt is added to the intptr_t conversion which is removed when
| converting back to the pointer type.

I am lost. Is this with all the implementations you have today for
which you want operator< to be a total order?

| 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)
|
|
| I'm not concerned about that, as p -> intptr_t(p) -> p has to result in a
| matching pointer. I don't see how that is workable if the implication above
| fails.

Hmm, remember I am very slow. Please explain this for me in further
details; I -think- I guess what you are saying but I would rather
make sure you spell out for me how this is working on today's machines
for which we need to make operator< a total ordering, and how they match
(or differ from existing implementations.)

-- Gaby

Received on 2013-10-18 06:13:32