At least for class types C++ can define a different format of the pointer for different types. Even reversing and shuffling the bits. Also pointer arithmetic can be done in multiples of the alignment or byte-wise. The implementations do not have to use the same ALU and instructions for pointer arithmetic like for other computations.   As already written, the trend goes to more abstraction. Compilers and CPUs get more complex, but also powerful, and safety is more important.   If one would introduce new low-level facilities into the language, then probably in a highly controlled way.   The compiler is allowed to cache memory contents in registers, to reorder instructions. How would you handle multi-threaded programs, what about transactional memory? Memory aliasing between different pointers? Memory/object lifetime guarantees?   By disallowing operations, compilers can try to detect it and give an error. Processor vendors can develop new safety features to automatically create an exception, if you do arithmetic with a nullptr, just to solve the same issue you brought up. It C++ now allows arithmetics on nullptr such safety features would be actively prevented.   AMD, Intel or ARM could introduce a new ADD function, which automatically creates an exception, if the first argument is the nullptr. The compilers would use that instruction, whenever pointer arithmetic is done. The compiler vendors can do the same with multiple instructions on current systems.   Why should the standard make that impossible?   -----Ursprüngliche Nachricht----- Von:zxuiji via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Do 31.07.2025 19:15 Betreff:Re: [std-proposals] Standardising 0xdeadbeef for pointers An:std-proposals_at_[hidden]; CC:zxuiji <gb2985_at_[hidden]>; 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. On Thu, 31 Jul 2025 at 18:12, Jason McKesson via Std-Proposals <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]> > wrote: On Thu, Jul 31, 2025 at 12:27 PM zxuiji <gb2985_at_[hidden] <mailto:gb2985_at_[hidden]> > wrote: > > It's still a pointer so it has pointer arithmetic, that's all that matters which therefore means it's not UB to use pointer arithmetic on nullptr or NULL The literal text of the standard in [expr.add]/4 clearly and unequivocally says that pointer arithmetic on a nullptr (except with a value of 0) is undefined behavior. This is not a matter of opinion. There is no room for debate or nuance. This is how C++ is defined. Pointers don't have "pointer arithmetic". Pointers to arrays have pointer arithmetic. A pointer to a single object can act as a pointer to an array of size one, but that's it. `nullptr` doesn't point to an array or a single object. Therefore, it cannot undergo pointer arithmetic (except with a value of 0). It does not matter if you can point to implementations such that it might have some value. It doesn't matter if you think it'd be really useful. The standard defines what is and is not defined behavior, and pointer arithmetic on a nullptr with a value other than 0 is UB. You don't have to like it, but that's the way it is and it is unlikely to change just because you want to do low-level shenanigans. > On Thu, 31 Jul 2025 at 17:25, Jason McKesson via Std-Proposals <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]> > wrote: >> >> On Thu, Jul 31, 2025 at 12:20 PM zxuiji <gb2985_at_[hidden] <mailto:gb2985_at_[hidden]> > wrote: >> > >> > >> > In what real world scenario has a pointer to an array not been a pointer capable of pointer arithmetic? >> >> Pointers to arrays *are* capable of pointer arithmetic. `nullptr` is >> not a "pointer to an array". It doesn't point to *anything*; that's >> kinda the point of it. >> >> > On Thu, 31 Jul 2025 at 17:16, Jason McKesson via Std-Proposals <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]> > wrote: >> >> >> >> On Thu, Jul 31, 2025 at 12:12 PM zxuiji <gb2985_at_[hidden] <mailto:gb2985_at_[hidden]> > wrote: >> >> > >> >> > how's it UB? it's basic pointer arithmetic, not derefencing a pointer. snprintf could provide the garauntee that within said address range it would be able to optionally prevent a segfault, which is enough for a developer to potentially see the log of caught instances before a hacker could cotton on and exploit it. >> >> >> >> [expr.add]/4: https://timsong-cpp.github.io/cppwp/expr.add#4 >> >> >> >> If the pointer is not a pointer to an array, pointer arithmetic is not >> >> defined (except in the case of a null pointer, but only if the added >> >> value is zero). `nullptr` is not a pointer to an array. Thus UB. >> >> >> >> > On Thu, 31 Jul 2025 at 17:08, Jason McKesson via Std-Proposals <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]> > wrote: >> >> >> >> >> >> On Thu, Jul 31, 2025 at 12:03 PM zxuiji via Std-Proposals >> >> >> <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]> > wrote: >> >> >> > >> >> >> > thiago I used NULL there to indicate what would be passed if something like the following occurred: >> >> >> > >> >> >> > int leng = 0, index = 0; >> >> >> > char *text = foo(&leng,&index); >> >> >> > // oops didn't check foo succeeded: >> >> >> > snprintf( buff, max, ".*s", leng, text + index ); >> >> >> >> >> >> That's interesting, but it's still UB the moment `text+index` is >> >> >> executed. Which happens *before* `snprintf` gets called. >> >> >> >> >> >> > On Thu, 31 Jul 2025 at 16:59, Thiago Macieira via Std-Proposals <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]> > wrote: >> >> >> >> >> >> >> >> On Thursday, 31 July 2025 08:56:26 Pacific Daylight Time zxuiji via Std- >> >> >> >> Proposals wrote: >> >> >> >> > snprintf( buff, max, "%.*s", length, NULL + index. ) could catch the >> >> >> >> > invalid pointer (so long as index is small) before a segfault can occur and >> >> >> >> > if stdlib is not in debug mode then allow the segafault to occur, otherwise >> >> >> >> > return -1 and set errno to some relevant value >> >> >> >> >> >> >> >> Do note that the program is UB before snprintf() was called. >> >> >> >> >> >> >> >> Could such a check function ever be used *before* UB happened? >> >> >> >> >> >> >> >> -- >> >> >> >> Thiago Macieira - thiago (AT) macieira.info <http://macieira.info> - thiago (AT) kde.org <http://kde.org> >> >> >> >>   Principal Engineer - Intel Platform & System Engineering >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> >> >> Std-Proposals mailing list >> >> >> >> Std-Proposals_at_[hidden] <mailto:Std-Proposals_at_[hidden]> >> >> >> >> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals >> >> >> > >> >> >> > -- >> >> >> > Std-Proposals mailing list >> >> >> > Std-Proposals_at_[hidden] <mailto:Std-Proposals_at_[hidden]> >> >> >> > https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals >> >> >> -- >> >> >> Std-Proposals mailing list >> >> >> Std-Proposals_at_[hidden] <mailto:Std-Proposals_at_[hidden]> >> >> >> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals >> >> -- >> >> Std-Proposals mailing list >> >> Std-Proposals_at_[hidden] <mailto:Std-Proposals_at_[hidden]> >> >> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals >> -- >> Std-Proposals mailing list >> Std-Proposals_at_[hidden] <mailto:Std-Proposals_at_[hidden]> >> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals -- Std-Proposals mailing list Std-Proposals_at_[hidden] <mailto: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