> One caveat is that bit_cast requires the bits to be a valid object representation of the target type. I don't think the standard offers any guarantees there.

a pointer can have a valid representation, even if the thing being pointed too might not.


________________________________
From: Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf of Lénárd Szolnoki via Std-Proposals <std-proposals_at_[hidden]>
Sent: Tuesday, January 28, 2025 7:13:02 PM
To: std-proposals_at_[hidden] <std-proposals_at_[hidden]>
Cc: Lénárd Szolnoki <cpp_at_[hidden]>
Subject: Re: [std-proposals] Make all data pointers intercompatible



On 28 January 2025 17:19:26 GMT, Andrey Semashev via Std-Proposals <std-proposals_at_[hidden]> wrote:
>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.

One caveat is that bit_cast requires the bits to be a valid object representation of the target type. I don't think the standard offers any guarantees there.

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

--
Std-Proposals mailing list
Std-Proposals_at_[hidden]
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals