Nevin Liber <nevin_at_[hidden]> writes:

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

This author is the author of the standard library which is part of the
implementation so know which of intptr_t or uintptr_t or any other
(extended) integer type it should chose.

-- Gaby