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