> Data pointer arithmetic is well-defined for all data pointer types, even if the pointer contains a value which is misaligned.

Well, I think sometimes it is not even defined at all.

class A;

A* a = getA();

A* b = a + 3; //invalid. Unknown size of A

Pointer arithmetic is only well-defined if the thing being pointed is also well-defined.

And there's nothing that says that pointer arithmetic has to be done by using integer arithmetic instructions, or that it couldn't use other funny instructions in the knowledge that certain types have certain alignment requirements, taking full advantage of the "as if" rule.
Thus, why I support the idea of over constraining could be counterproductive.



________________________________


From: Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf of Jeremy Rifkin via Std-Proposals <std-proposals_at_[hidden]>
Sent: Tuesday, January 28, 2025 5:42:20 PM
To: std-proposals_at_[hidden]pp.org <std-proposals_at_[hidden]>
Cc: Jeremy Rifkin <rifkin.jer_at_[hidden]>
Subject: Re: [std-proposals] Make all data pointers intercompatible

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

On one hand I understand where you're coming from and why this might be desirable. But, on the other hand, it has always been perceived by WG14 and WG21 that there's value in not over-constraining. CHAR_BIT is a great example of this, though that may be constrained by P3477 due to practicality. Pointer constraints might fall into this bucket too.

But what's the motivation? What do you need to write that you can't now but could if pointers had different guarantees?

Cheers,
Jeremy

On Tue, Jan 28, 2025 at 9:29 AM Frederick Virchanza Gotham via Std-Proposals <std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>> wrote:
On Tue, Jan 28, 2025 at 3:16 PM organicoman wrote:
>
> The resulting pointer is unspecified: means dereferencing it is UB.
> Because the compiler is not allowed to alter the bits of A. It will keep it as given.
>
> I can do the following.
>
> double* ptr = reinterpret_cast<double*>(0x7fff934a9d83); // misaligned for double
>
> ptr value will stay 0x7fff934a9d83, but it is unusable otherwise:
> *ptr is UB
> ++ptr is UB
> --ptr is UB
> ptr+int the result is UB.
> ...etc


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

Then I want "++ptr" to add 8 to it, giving 0x7FFF934A9D8B. I want this
to be well-defined behaviour.

Of course though, to dereference it would still be UB.

By the way . . . . . just in case anyone's wondering . . . . . what
I'm asking for is already possible with all modern C++ compilers, I
just want it to be written in stone in the Standard.
--
Std-Proposals mailing list
Std-Proposals_at_[hidden]<mailto:Std-Proposals_at_[hidden]>
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals