C++ Logo


Advanced search

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

From: Nevin Liber <nevin_at_[hidden]>
Date: Thu, 17 Oct 2013 23:06:21 -0500
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) 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:


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

Received on 2013-10-18 06:07:03