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.


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