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