Jeffrey Yasskin <jyasskin_at_[hidden]> writes:

| 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.

Indeed, that is the implementation abstract model used by CompCert.
Objects are allocated from set of blocks. The fact that operator< on
unrelated objects is undefined gives CompCert a latitude on the
represetation of blocks, both the high level and at the lower level.

| > 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.
| > -----------------------------------------------------------------------------------
| _______________________________________________
| ub mailing list
| ub_at_[hidden]
| http://www.open-std.org/mailman/listinfo/ub