[ub] Justification for < not being a total order on pointers?

Gabriel Dos Reis gdr at axiomatics.org
Fri Oct 18 06:17:25 CEST 2013


Nevin Liber <nevin at eviloverlord.com> writes:

| On 17 October 2013 10:19, Gabriel Dos Reis <gdr at axiomatics.org> wrote:
| 
|     Nevin Liber <nevin at eviloverlord.com> 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


More information about the ub mailing list