But in your paper you copy the contents to unaligned by copy the object
contents into byte representation. That is fine. It's not UB.
And everytime you access It, you put It on aligned memory first, so its ok
too.
I don't see how this paper requires any change

Em qui., 30 de jan. de 2025, 06:18, Frederick Virchanza Gotham via
Std-Proposals <std-proposals_at_[hidden]> escreveu:

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