Subject: Re: [ub] Justification for < not being a total order on pointers?
From: Gabriel Dos Reis (gdr_at_[hidden])
Date: 2013-10-17 23:13:15
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
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.)
SG12 list run by herb.sutter at gmail.com