Date: Tue, 28 Jan 2025 20:19:26 +0300
On 1/28/25 18:29, Frederick Virchanza Gotham via Std-Proposals wrote:
>
> I want the C++26 Standard to say that the implementation shall have
> pointers into data memory, and that the size of these pointers shall
> be implementation-defined (e.g. 32-Bit or 64-Bit).
> All data pointer types are exactly the same (same size, same
> alignment, same representation).
> Data pointer arithmetic is well-defined for all data pointer types,
> even if the pointer contains a value which is misaligned. So if we
> have a pointer to a misaligned double:
>
> double *ptr = reinterpret_cast<double*>(0x7fff934a9d83);
It seems, you can already use bit_cast if you just want to convert
between unrelated pointer types and require that they have the same
size. So long as bit_cast compiles, you have your conversion and it is
guaranteed to not alter the pointer representation.
> Then I want "++ptr" to add 8 to it, giving 0x7FFF934A9D8B. I want this
> to be well-defined behaviour.
If you want arbitrary arithmetics, I don't see why you need pointers to
begin with. Just operate on uintptr_t.
Pointers *are supposed to point to objects* (or functions, or storage,
but that's beside the point). That is, a pointer is supposed to store an
address in memory, and there are rules as to which addresses are valid
for certain object types and which are not. For example, on a 32-bit
platrorm, 0xFFFF'FFFE might be a valid address for a uint16_t but not
for uint32_t because there simply isn't space for that object at that
address. Alignment is another requirement. So stop treating pointers as
arbitrary integers - they are purposely distinct from integers because
of these rules.
>
> I want the C++26 Standard to say that the implementation shall have
> pointers into data memory, and that the size of these pointers shall
> be implementation-defined (e.g. 32-Bit or 64-Bit).
> All data pointer types are exactly the same (same size, same
> alignment, same representation).
> Data pointer arithmetic is well-defined for all data pointer types,
> even if the pointer contains a value which is misaligned. So if we
> have a pointer to a misaligned double:
>
> double *ptr = reinterpret_cast<double*>(0x7fff934a9d83);
It seems, you can already use bit_cast if you just want to convert
between unrelated pointer types and require that they have the same
size. So long as bit_cast compiles, you have your conversion and it is
guaranteed to not alter the pointer representation.
> Then I want "++ptr" to add 8 to it, giving 0x7FFF934A9D8B. I want this
> to be well-defined behaviour.
If you want arbitrary arithmetics, I don't see why you need pointers to
begin with. Just operate on uintptr_t.
Pointers *are supposed to point to objects* (or functions, or storage,
but that's beside the point). That is, a pointer is supposed to store an
address in memory, and there are rules as to which addresses are valid
for certain object types and which are not. For example, on a 32-bit
platrorm, 0xFFFF'FFFE might be a valid address for a uint16_t but not
for uint32_t because there simply isn't space for that object at that
address. Alignment is another requirement. So stop treating pointers as
arbitrary integers - they are purposely distinct from integers because
of these rules.
Received on 2025-01-28 17:19:29