Date: Sun, 23 Jul 2023 07:26:46 +0100
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
>
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
>
Received on 2023-07-23 06:26:56