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
>