Date: Fri, 18 Oct 2013 00:53:15 -0500
Nevin Liber <nevin_at_[hidden]> writes:
| 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.
Great! So, this isn't any of the architecture you care about.
| 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).
I used the phrase "exotic architecture" in a specific context, yes.
But, I am unsure how that is supposed to affect your overall argument
and goal.
| 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.
Indeed, the standards do not legislate peseudocodes :-)
But, again, remember we are talking about the implementation of
std::less<T*> provided by the implementation!
| If that isn't what you meant by "exotic architecture", please elaborate on what
| you do mean.
What is more to elaborate about 'exhotic architecture', since by your
own statements, they don't exist (to your knowledge)?
-- Gaby
| 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.
Great! So, this isn't any of the architecture you care about.
| 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).
I used the phrase "exotic architecture" in a specific context, yes.
But, I am unsure how that is supposed to affect your overall argument
and goal.
| 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.
Indeed, the standards do not legislate peseudocodes :-)
But, again, remember we are talking about the implementation of
std::less<T*> provided by the implementation!
| If that isn't what you meant by "exotic architecture", please elaborate on what
| you do mean.
What is more to elaborate about 'exhotic architecture', since by your
own statements, they don't exist (to your knowledge)?
-- Gaby
Received on 2013-10-18 07:53:32