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

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
>