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.

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.



>
>
>> 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
>>>>
>>> --
>>> Std-Discussion mailing list
>>> Std-Discussion_at_[hidden]
>>> https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion
>>>
>> --
>> Richard Hodges
>> hodges.r_at_[hidden]
>> office: +44 2032 898 513
>> home: +376 861 195
>> mobile: +376 380 212
>>
>> --
Richard Hodges
hodges.r_at_[hidden]
office: +44 2032 898 513
home: +376 861 195
mobile: +376 380 212