On July 31, 2025 2:13:28 p.m. EDT, connor horman via Std-Proposals <std-proposals@lists.isocpp.org> wrote:
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++.
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 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@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals