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? It seems that might be detrimental to correctness, security and/or
optimization.



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