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

> Nevin Liber <nevin_at_[hidden]> writes:
>
> | But, even if segmented architectures, unlikely though it is, do come
> back, the
> | ordering problem still has to be addressed, as std::less<T*> is required
> to
> | totally order pointers. I just want operator< to be an alternate
> spelling for
> | that property.
>
> I will repeat this again: std::less<T*> is absolutely not a problem,
> because this
>
> return intptr_t(p) < intptr_t(q);
>
> is valid and portable definition that requires no other special handling.
>

1. intptr_t is optional (n3797 18.4.1) Therefore, it isn't portable.

2. The only guarantee I can find about intptr_t is in the C standard
(n1570 in their document numbering scheme) 7.20.1.4 Integer types capable
of holding object pointers:

The following type designates a signed integer type with the property that
any valid

pointer to *void *can be converted to this type, then converted back to
pointer to *void*,

and the result will compare equal to the original pointer:

*intptr_t*


I see no ordering guarantees.

3. Let's say I'm on a 16-bit architecture. I have an array from address
0x7fff-0x8001. The obvious conversion doesn't preserve ordering, as 0x7fff
< 0x8001 as addresses but 32767 > -32767 as integers. This is trivially
addressed by moving to the also optional uintptr_t, but then...

4. I can imagine on a system concerned about security that a
process-specific salt is applied to the address when converted to an
integer (not dissimilar to that proposed for hashing in n3333). As long as
the process can be reversed, I don't see anything in the standard which
precludes it. It can be something as simple as adding a fixed offset to
the value and ordering is broken.


Again, what should we recommend to this author? If we are going to tell
him to rely on non-portable, non-guaranteed behavior he might as well keep
relying on pointers being totally ordered.

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