C++ Logo

SG12

Advanced search

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
| 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


SG12 list run by herb.sutter at gmail.com