C++ Logo

std-proposals

Advanced search

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

From: Frederick Virchanza Gotham <cauldwell.thomas_at_[hidden]>
Date: Thu, 30 Jan 2025 09:18:41 +0000
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

Received on 2025-01-30 09:18:54