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

James Dennett jdennett at google.com
Thu Oct 17 21:38:05 CEST 2013


On Thu, Oct 17, 2013 at 8:19 AM, 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.

I think it's not useful though; nothing guarantees that p == q =>
intptr_t(p) ==intptr_t(q), so far as I know, much less that p<q =>
intptr_t(p) < intptr_t(q).  (I'd be happy to be wrong.)  (In other
words, it's not suitable as a portable definition of std::less<T*>.)

Or do we require, somehow, the conversion to an integral type to
normalize segmented addresses, rather than just concatenating them
(e.g., imagine a platform where the effective address is
(hiword<<16)+loword, which permits many representations of the same
address.  Comparisons on such pointers need to deal with that
equivalence relation there, but converting to intptr_t by just taking
(hiword<<32)+loword appears valid.

-- James


More information about the ub mailing list