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

Gabriel Dos Reis gdr at axiomatics.org
Fri Oct 18 06:13:15 CEST 2013


Nevin Liber <nevin at eviloverlord.com> writes:

| On 17 October 2013 19:18, Gabriel Dos Reis <gdr at axiomatics.org> 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



More information about the ub mailing list