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

Nevin Liber nevin at eviloverlord.com
Fri Oct 18 06:06:21 CEST 2013


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.
-- 
 Nevin ":-)" Liber  <mailto:nevin at eviloverlord.com>  (847) 691-1404
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.open-std.org/pipermail/ub/attachments/20131017/12c73b55/attachment.html 


More information about the ub mailing list