It's moot what assembly defines as a pointer. You aren't writing in
assembly, or even portable assembly. You are writing in C or C++ (or some
other relatively high-level language). They have a different definition of
pointer arithmetic, because it suits them to do so. You aren't writing C++
code for an x86 CPU, for but an Abstract Machine that happens to be
partially emulated by an x86_64 CPU, after being translated by a compiler.
The AM decides what defined behaviour each operation has, or even if there
is no defined behaviour. The compiler then is responsible for translating
only the observable results of at least one execution of a given program,
if all have defined behaviour, and has no responsibility to correctly
translate any program that the AM decides does has a valid execution for a
given input that results in undefined behaviour, other than what behaviour
arises prior to an observable checkpoint. [intro.abstract]#6.
Any proposal to change C++ approaches the standard from the perspective of
the standard. If your compiler cooperates, you may decide to write program
in a language syntactically equivalent to C++ that has direct semantic
correspondence with your underlying machine, but this is contingent on your
compiler, and the C++ Standards Committee does not concern itself with the
behaviour of this programming language. Nor likely does your compiler, and
the correspondance is merely happenstance of its largely correct
implementation of C++.

On Thu, 31 Jul 2025 at 14:01, zxuiji via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> You can't just redfine the meaning of a pointer, asm defined it years ago
> and C etc just have to follow on, and asm defined it to have arithmetic so
> arithmetic it shall, *always*. If a vendor decides to make the add
> instruction throw an exception then the CPU is already dead in the water
> because no gamer will want it, no business will need it for their server
> more than one that allows it, there is literally no value to disabling
> pointer arithmetic and only cons.
>
> On Thu, 31 Jul 2025 at 18:40, Andrey Semashev via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>> On 31 Jul 2025 20:29, zxuiji via Std-Proposals wrote:
>> > nullptr MUST hold a value, not matter if that value is valid or not,
>> > therefore it will ALWAYS have pointer arithmetic available. It is utter
>> > insanity to say a pointer might not have pointer arithmetic.
>>
>> nullptr might be a trap value, so applying any sort of math to it (or
>> dereference it) would cause a hardware fault.
>>
>> PS: Cheetos crust, I can't believe this thread is still going..
>>
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>