On Sun, Jul 23, 2023, 18:59 Lénárd Szolnoki <cpp_at_[hidden]> wrote:

> On Sun, 2023-07-23 at 18:09 +0200, Edward Catmur via Std-Discussion
> wrote:
> >
> >
> > On Sun, Jul 23, 2023, 17:46 Richard Hodges <hodges.r_at_[hidden]>
> > wrote:
> > >
> > >
> > > On Sun, 23 Jul 2023 at 17:39, Edward Catmur
> > > <ecatmur_at_[hidden]> wrote:
> > > >
> > > >
> > > > On Sun, Jul 23, 2023, 17:16 Richard Hodges <hodges.r_at_[hidden]>
> > > > wrote:
> > > > > In the light of the C++ memory model being specified in terms
> > > > > of a virtual machine, it seems an anomaly to me that the memory
> > > > > model is not also specified in terms of a linear address space.
> > > > >
> > > > > In this model, segmentation would be merely an implementation
> > > > > detail. This would remove an enormous amount of unnecessary
> > > > > confusion from the language.
> > > > >
> > > > > If people wanted to work in terms of small segments or paged
> > > > > program memory, that is surely something that should be covered
> > > > > by compiler extensions, no?
> > > >
> > > > But would that mean that every pointer is reachable from every
> > > > other pointer?
> > > >
> > >
> > >
> > > The language is full of constructs to allow pointers to reach when
> > > they “shouldn’t”. Reinterpret_casr, launder, etc.
> > >
> > > I’m ok with this, and I’m OK with it being easier to work with
> > > memory.
> >
> > I don't really see launder as the same kind of thing. If by
> > reinterpret_cast you mean performing arithmetic in uintptr_t, then by
> > doing so you're explicitly eschewing guardrails and optimization
> > opportunities.
> >
> > And uintptr_t is the escape hatch here. Perhaps making that
> > conversion more tied down would be the way to go, if we can be
> > certain that the translation places the address part ends up in the
> > low bits. And then if we could be sure that std::less is consistent
> > with uintptr_t, non hostility would naturally result.
> >
>
> Pointer comparison through uintptr_t is even less specified than
> through operator<, let alone std::less.
>

Well, yes. But it's not readily apparent to me what benefit we gain from
that underspecification, whereas the argument for keeping < as it is is
pretty clear.

And don't most if not all vendors implement std::less compatible with,
often in terms of uintptr_t?

> >
> > > > It seems that might be detrimental to correctness, security
> > > > and/or optimization.
> > > >
> > >
> > >
> > > I’m not proposing to remove wording describing the behaviour of
> > > aliased pointers.
> >
> > I'm not sure what you mean by this. Would a tagged pointer
> > architecture where subtracting or comparing pointers with different
> > tags faults still be permitted? Because that's what I'm most
> > concerned we might lose with a switch to a flat model, along with the
> > possibility of sanitizers to pretend a tagged architecture for
> > identifying bugs, and optimizers to pretend one for the performance
> > benefit.
> >
> >
> > >
> > > >
> > > >
> > > > >
> > > > > On Sun, 23 Jul 2023 at 08:27, Edward Catmur via Std-Discussion
> > > > > <std-discussion_at_[hidden]> wrote:
> > > > > >
> > > > > >
> > > > > > On Sun, 23 Jul 2023 at 06:37, Will Hawkins via Std-Discussion
> > > > > > <std-discussion_at_[hidden]> wrote:
> > > > > > > On Sat, Jul 22, 2023 at 2:47 PM Brian Bi via Std-Discussion
> > > > > > > <std-discussion_at_[hidden]> wrote:
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > On Sat, Jul 22, 2023 at 2:40 PM Lénárd Szolnoki via Std-
> > > > > > > > Discussion <std-discussion_at_[hidden]> wrote:
> > > > > > > > >
> > > > > > > > > Hi,
> > > > > > > > >
> > > > > > > > > Given these two arrays, each being a complete object:
> > > > > > > > >
> > > > > > > > > int a[2];
> > > > > > > > > int b[2];
> > > > > > > > >
> > > > > > > > > The partial ordering of the addresses (defined by the
> > > > > > > > > operator <) of
> > > > > > > > > the int objects within is:
> > > > > > > > >
> > > > > > > > > 1. &a[0] < &a[1]
> > > > > > > > > 2. &b[0] < &b[1]
> > > > > > > > >
> > > > > > > > > A hostile strict total order that is consistent with
> > > > > > > > > this is
> > > > > > > > > &a[0] < &b[0] < &a[1] < &b[1].
> > > > > > > > >
> > > > > > > > > Is there wording that prevents the implementation
> > > > > > > > > defined strict total
> > > > > > > > > order to manifest like this?
> > > > > > > >
> > > > > > > >
> > > > > > > > Not as far as I can tell.
> > > > > > >
> > > > > > > Does the last clause of
> > > > > > > https://eel.is/c++draft/intro.object#9 have
> > > > > > > anything to say about this situation?
> > > > > > >
> > > > > > > ... otherwise, they have distinct addresses and occupy
> > > > > > > disjoint bytes
> > > > > > > of storage."
> > > > > > >
> > > > > >
> > > > > >
> > > > > > "Disjoint" just means that incrementing a pointer to the
> > > > > > first byte of one object through to the last byte of that
> > > > > > object will not yield a pointer to a byte of the other
> > > > > > object.
> > > > > >
> > > > > > The "hostile std::less<>" posited would have p R q and q R
> > > > > > p+1 for some byte pointer p - that is, q is ordered between p
> > > > > > and p+1 even though p and p+1 point to adjacent bytes of
> > > > > > storage.
> > > > > >
> > > > > > Recall that std:less<> is just a strict total order that
> > > > > > linearly extends each strict partial order on the pointers to
> > > > > > objects and storage. There's nothing at present to say that
> > > > > > it respects disjointedness of distinct objects.
> > > > > >
> > > > > > > Sincerely,
> > > > > > > Will
> > > > > > >
> > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > One problem with this is that std::less is commonly
> > > > > > > > > used to check if a
> > > > > > > > > given pointer points within a range. If such a
> > > > > > > > > manifestation is
> > > > > > > > > possible then such usages are incorrect (or at least
> > > > > > > > > theoretically not
> > > > > > > > > portable).
> > > > > > > >
> > > > > > > >
> > > > > > > > I agree that this is something that should be banned. To
> > > > > > > > be specific, `&a[0] < &b[0] < &a[1] < &b[1]` is probably
> > > > > > > > the sort of thing that is supposed to be allowed, because
> > > > > > > > the idea behind `<` not being a total order is to support
> > > > > > > > segmented architectures where e.g. it might only compare
> > > > > > > > the offset part of the address. But `std::less` always
> > > > > > > > has to take into account both the segment and offset, so
> > > > > > > > I can't see any reason why it should be allowed to give
> > > > > > > > this "hostile" order.
> > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Cheers,
> > > > > > > > > Lénárd
> > > > > > > > >
> > > > > > > > > P.S. Someone pointed this out to me on the #include
> > > > > > > > > <C++> discord.
> > > > > > > > > --
> > > > > > > > > Std-Discussion mailing list
> > > > > > > > > Std-Discussion_at_[hidden]
> > > > > > > > >
> https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Brian Bi
> > > > > > > > --
> > > > > > > > Std-Discussion mailing list
> > > > > > > > Std-Discussion_at_[hidden]
> > > > > > > > https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion
> > > > > > > --
> > > > > > > Std-Discussion mailing list
> > > > > > > Std-Discussion_at_[hidden]
> > > > > > > https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion
>
>