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

Gabriel Dos Reis gdr at axiomatics.org
Mon Aug 26 20:43:07 CEST 2013


Jeffrey Yasskin <jyasskin at google.com> writes:

| On Mon, Aug 26, 2013 at 11:15 AM, Olivier Giroux <OGiroux at nvidia.com> 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 google.com]
| > 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 eviloverlord.com> wrote:
| >> On 26 August 2013 11:00, Jeffrey Yasskin <jyasskin at google.com> 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 eviloverlord.com>  (847) 691-1404
| >>
| >> _______________________________________________
| >> ub mailing list
| >> ub at isocpp.open-std.org
| >> 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 isocpp.open-std.org
| http://www.open-std.org/mailman/listinfo/ub


More information about the ub mailing list