C++ Logo

SG12

Advanced search

Subject: Re: [ub] Justification for < not being a total order on pointers?
From: Nevin Liber (nevin_at_[hidden])
Date: 2013-10-18 00:15:27


On 17 October 2013 23:13, Gabriel Dos Reis <gdr_at_[hidden]> wrote:

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

Nope. My contention has consistently been that platforms serviced by C++11
compilers today have totally ordered pointers with respect to operator<.

You are the one who used the words "exotic architecture" (see what I quoted
above).

On a system with 16-bit pointers, 16-bit unsigned shorts, 32 bit unsigned
longs and 32-bit uintptr_t's, the following pseudocode is perfectly
reasonable:

uintptr_t cast(T* p) { static unsigned long salt; return ++salt << 16 |
(unsigned short)p; }
T* cast(uintptr_t i) { return (T*)(unsigned short)p; }

I see nothing in the standard which would make that pseudocode illegal.

If that isn't what you meant by "exotic architecture", please elaborate on
what you do mean.

-- 
 Nevin ":-)" Liber  <mailto:nevin_at_[hidden]>  (847) 691-1404



SG12 list run by herb.sutter at gmail.com