The pointer char32_t* would not work pointing to unaligned memory anyway.   So either it is pointing to object-internal storage. Then it changes with relocation.   Or it is pointing to object-external storage. Then its value does not change with relocation.   The difficulty seems to stem from the fact that you want to distinguish both cases by the pointer value and keep a pointer value to internal storage even in the packed format, as the address of the packed storage (+offset) is the only way for identifying the first case and storing an offset.   Perhaps an unmodified basic_string with such internal storage is not suited for exotic architectures and unaligned packing in a general non-specific way. For a specific architecture one could use unused memory locations to signify the first case and code an offset from the start of the object with that range of numbers.   You are talking about implementation (of the custom unaligned relocator for a basic_string implementation). What do you gain by standardizing pointer size? Some exotic architectures would not be C++ compliant any more for current standard versions. Your (hacky) solution for an implementation of the unaligned relocator would work without changes on any platform compliant to the current standard instead of on nearly all of them.     -----Ursprüngliche Nachricht----- Von:Frederick Virchanza Gotham via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Do 09.05.2024 12:42 Betreff:Re: [std-proposals] Make all data pointers intercompatible An:std-proposals_at_[hidden]; CC:Frederick Virchanza Gotham <cauldwell.thomas_at_[hidden]>; I reply to Jonathan and Sebastian in series below. On Thu, May 9, 2024 at 11:25 AM Jonathan Wakely wrote: > >> Therefore >> this platform can be described as follows: >>     (1) sizeof(char*) > sizeof(int*) > > > Why would that be true? > > CHAR_BIT == 16 which means every char has 16 bits and > so is aligned to a 16-bit boundary as well. That's what > CHAR_BIT means, by definition. Yeah you're right, I was getting confused with how the Texas Instruments does things. Let me try again:    T = int    CHAR_BIT == 8    sizeof(int) == 4    UINT_MAX == 4294967295 The smallest addressable unit of memory that the CPU can read or write is actually 16 bits, however the compiler is hiding this fact. The compiler has set CHAR_BIT==8, and so whenever it encounters a char*, the compiler needs a memory address combined with an offset, and so there are two possibilities:    Possibility 1:    sizeof(char*)  >  sizeof(int*)    Possibility 2:    sizeof(char*)  ==  sizeof(int*) (but the latter has extra bits always set to zero) On Thu, May 9, 2024 at 11:25 AM Jonathan Wakely wrote: > > Only if it's misaligned by 8 bits. What about being misaligned by 4 bits? > Or 7? What is the problem you're solving? Misaligned by CHAR_BIT bits (on a compiler where CHAR_BIT is smaller than the CPU's smallest addressable unit of memory). On Thu, May 9, 2024 at 11:31 AM Sebastian Wittmeier wrote: > > But a T is not an unaligned<T>. You need code for copying memory > to and from aligned space, when calling member functions. I was writing code to relocate an std::string into unaligned memory. An std::string internally contains a "char*", so there's no problem with it being unaligned. But let's say we're dealing with a:    std::basic_string<char32_t> So it contains internally a pointer to a char32_t. If sizeof(char*) > sizeof(char32_t*) then it won't be possible to store the address of an unaligned char32_t inside a char32_t*. -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals