On Sun, Jul 23, 2023, 17:16 Richard Hodges <hodges.r@gmail.com> 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@lists.isocpp.org> wrote:On Sun, 23 Jul 2023 at 06:37, Will Hawkins via Std-Discussion <std-discussion@lists.isocpp.org> wrote:On Sat, Jul 22, 2023 at 2:47 PM Brian Bi via Std-Discussion
<std-discussion@lists.isocpp.org> wrote:
>
>
>
> On Sat, Jul 22, 2023 at 2:40 PM Lénárd Szolnoki via Std-Discussion <std-discussion@lists.isocpp.org> 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@lists.isocpp.org
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion
>
>
>
> --
> Brian Bi
> --
> Std-Discussion mailing list
> Std-Discussion@lists.isocpp.org
> https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion
--
Std-Discussion mailing list
Std-Discussion@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion
Std-Discussion mailing list
Std-Discussion@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion