On Mon, Aug 26, 2013 at 11:15 AM, Olivier Giroux <OGiroux_at_[hidden]> wrote:
> It sounds like this rule gives permission to implementations to compare pointers based on offsets only instead of the full effective address. The effective address must be unique however, per the last sentence of 1.7.1 -- question: does a user have to cast to intptr_t first, before asserting this property?

I think that's how we're intended to order addresses if we're not
going through std::less.

> I think that for GPUs we also prefer to take the simple intuitive path: just use the effective address in the comparison.

Great!

> Note that we don't always respect that last sentence of 1.7.1 right now, but that's neither driven nor supported by constraints on operator<(T*).

For that matter, neither do POSIX systems that can mmap memory into
more than one address.

> Olivier
>
> -----Original Message-----
> From: Jeffrey Yasskin [mailto:jyasskin_at_[hidden]]
> Sent: Monday, August 26, 2013 9:32 AM
> To: Nevin Liber; Olivier Giroux
> Cc: ub
> Subject: Re: [ub] Justification for < not being a total order on pointers?
>
> On Mon, Aug 26, 2013 at 9:12 AM, Nevin Liber <nevin_at_[hidden]> wrote:
>> On 26 August 2013 11:00, Jeffrey Yasskin <jyasskin_at_[hidden]> wrote:
>>>
>>>
>>> Could someone explain why we need to allow operator<(T*) to be a
>>> non-order?
>>
>>
>> It comes from C.
>
> Yeah, C11 still makes it undefined behavior, not just unspecified: 6.5.8p5
>
>> I believe it comes from the days of segmented architectures.
>>
>> I do not know of any modern machines that have such architectures and
>> have
>> C++11 compilers for them. Whenever it comes up for discussion on
>> C++various
>> reflectors, no one has mentioned one either.
>
> Now that you mention it, GPUs might be an example. Olivier, do you depend on this restriction? (Rest of thread at
> http://www.open-std.org/pipermail/ub/2013-August/000095.html)
>
> I had assumed that it was an optimization thing nowadays, as Gaby said, and maybe if the optimizations aren't that significant we could drop them.
>
>> I for one would like to see
>> this restriction go away.
>>
>> Armchair thought: maybe we should propose a total ordering for
>> pointers (for C++17 at this point) and see if anyone objects?
>>
>>
>> All that being said, I believe Library is inconsistent in its use of
>> operator< vs. std::less<T>, and that needs to be addressed separately.
>> Pointers are the current poster child for the issue but user code
>> might be specializing std::less as well.
>> --
>> Nevin ":-)" Liber <mailto:nevin_at_[hidden]> (847) 691-1404
>>
>> _______________________________________________
>> ub mailing list
>> ub_at_[hidden]
>> http://www.open-std.org/mailman/listinfo/ub
>>
> -----------------------------------------------------------------------------------
> This email message is for the sole use of the intended recipient(s) and may contain
> confidential information. Any unauthorized review, use, disclosure or distribution
> is prohibited. If you are not the intended recipient, please contact the sender by
> reply email and destroy all copies of the original message.
> -----------------------------------------------------------------------------------