C++ Logo

std-proposals

Advanced search

Re: [std-proposals] Make all data pointers intercompatible

From: Breno Guimarães <brenorg_at_[hidden]>
Date: Thu, 30 Jan 2025 09:02:21 -0300
No, i'm missing. I assumed there was a relocation function exactly to
correctly address this. Sorry

Em qui., 30 de jan. de 2025, 08:59, Jonathan Wakely <cxx_at_[hidden]>
escreveu:

>
>
> On Thu, 30 Jan 2025 at 11:35, Breno Guimarães <brenorg_at_[hidden]> wrote:
>
>> It doesnt memcpy. It copies the contents with the relocation function,
>> which is fine If implemented correctly keeping the invariants. I guess
>> that's the purpose of the relocation function
>>
>
> The relocation function uses _Relocator_Custom< std::basic_string<T>>,
> right? Which uses RelocatorForBasicString::relocate, which uses memcpy. Am
> I missing something?
>
>
>
>
>
>
>>
>> Em qui., 30 de jan. de 2025, 08:32, Jonathan Wakely via Std-Proposals <
>> std-proposals_at_[hidden]> escreveu:
>>
>>>
>>>
>>> On Thu, 30 Jan 2025 at 10:10, Sebastian Wittmeier via Std-Proposals <
>>> std-proposals_at_[hidden]> wrote:
>>>
>>>> Can p point to the heap or to the beginning of buf?
>>>>
>>>
>>> Yes.
>>>
>>>
>>>> Or can it also point to the middle of buf?
>>>>
>>>
>>> No.
>>>
>>>
>>>>
>>>>
>>>> Couldn't you in the first case do the following?
>>>>
>>>>
>>>>
>>>> If p is pointing to buf,
>>>>
>>>> set it to the first aligned byte of buf in the unaligned memory.
>>>>
>>>
>>> That would break invariants of the libstdc++ basic_string, which uses `p
>>> == buf` to detect when the string is no heap allocated. If you point p to
>>> the middle of bug then the destructor will do deallocate(p, capacity()+1)
>>> which will try to delete non-allocated memory.
>>>
>>> The solution is: stop trying to mess with the internals of std::string.
>>> Come up with a better motivating example.
>>>
>>>
>>>
>>>>
>>>> If p is pointing to the heap,
>>>>
>>>> keep it.
>>>>
>>>>
>>>>
>>>> And then just store the byte representation of the pointer.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> No problems with size, no problems with underlying pointer
>>>> representation.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> In the second case, you need enough possible pointer values inside the
>>>> new memory to represent each positon within buf, p could point to.
>>>>
>>>>
>>>> -----Ursprüngliche Nachricht-----
>>>> *Von:* Frederick Virchanza Gotham via Std-Proposals <
>>>> std-proposals_at_[hidden]>
>>>> *Gesendet:* Do 30.01.2025 10:18
>>>> *Betreff:* Re: [std-proposals] Make all data pointers intercompatible
>>>> *An:* std-proposals_at_[hidden];
>>>> *CC:* Frederick Virchanza Gotham <cauldwell.thomas_at_[hidden]>;
>>>> On Thu, Jan 30, 2025 at 12:14 AM Thiago Macieira wrote:
>>>> >
>>>> > On Wednesday 29 January 2025 Frederick wrote:
>>>> >>
>>>> > > All I'm asking for is that pointer arithmetic will be well-defined
>>>> for
>>>> > > all pointer types even when the address is unaligned -- and I think
>>>> > > this won't affect any optimisers. In fact it won't even require a
>>>> > > change to any modern compilers.
>>>> >
>>>> > You haven't answered the most important question: why?
>>>> >
>>>> > What does this allow you to do that it didn't before?
>>>>
>>>>
>>>> I've mentioned the reason a few times but I'll spell it out here. The
>>>> libstdc++ implementation of 'std::string' contains a pointer into its
>>>> own buffer, sort of like:
>>>>
>>>> class string {
>>>> char buf[16];
>>>> char *p;
>>>> string(void) { p = buf; }
>>>> };
>>>>
>>>> If I relocate a string from aligned memory into unaligned memory, then
>>>> everything will be okay because the pointer 'p' points to something
>>>> that doesn't have any alignment requirements.
>>>>
>>>> But now let's consider basic_string<char32_t>:
>>>>
>>>> class u32string {
>>>> char32_t buf[16];
>>>> char32_t *p;
>>>> u32string(void) { p = buf; }
>>>> };
>>>>
>>>> The pointer 'p' points to something that has an alignment requirement
>>>> of 4. There are two consequences to this:
>>>> (1) Strictly speaking, sizeof(void*) might be bigger than
>>>> sizeof(char32_t*). Of course this is just a fairytale and no such
>>>> computer exists nowadays, but nonetheless the Standard needlessly
>>>> accommodates it.
>>>> (2) If I set 'p' to an unaligned address, maybe the lower 2 bits
>>>> won't retain their value because of UB.
>>>>
>>>> On Page 5 of this paper, I relocate a basic_string into unaligned
>>>> memory: http://www.virjacode.com/papers/unaligned_latest.pdf
>>>> --
>>>> Std-Proposals mailing list
>>>> Std-Proposals_at_[hidden]
>>>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>>>
>>>> --
>>>> Std-Proposals mailing list
>>>> Std-Proposals_at_[hidden]
>>>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>>>
>>> --
>>> Std-Proposals mailing list
>>> Std-Proposals_at_[hidden]
>>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>>
>>

Received on 2025-01-30 12:02:35