A C++ implementation could keep track of all constructed objects [and of all memory regions, where implicit object creation (like proposed in https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p0593r6.html) is possible.] Any pointers not following this rule could be prohibited. E.g. for safety or performance reasons or just the inner working of a special computer. The pointers not necessarily have to point to flat memory. An implementation could subdivide a pointer into several bitfields with different meanings. Some bits for access rights, authentication, storage location/NUMA, dynamic type of the memory pointed to, ... There is a lot allowed. Documents like standards can and do redefine their used terms. Only because it is a "pointer" you cannot assume that you can do all kind of legal operations on it.   -----Ursprüngliche Nachricht----- Von:zxuiji via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Do 31.07.2025 18:46 Betreff:Re: [std-proposals] Standardising 0xdeadbeef for pointers An:std-proposals_at_[hidden]; CC:zxuiji <gb2985_at_[hidden]>; How's it undefined? Take my MAX_INVALID_ADDRESS for example, let's say NULL is defined as and nullptr is likewise defined to use 0xdeadbeef. 0xdeadbeef +- MAX_INVALID_ADDRESS would be the range for the inline to check against. without or without a 0 based NULL/nullptr the compiler can optimise out the addition/subtraction applied to NULL & nullptr to check the range when compiling it for a library. Granted I prefer being able to check the upper bits but that's something I would leave to a glibc/ucrt function to provide a extension function for. On Thu, 31 Jul 2025 at 17:40, Thiago Macieira via Std-Proposals <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]> > wrote: On Thursday, 31 July 2025 09:41:09 Pacific Daylight Time zxuiji via Std- Proposals 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 null*ptr *or* > NULL* You're missing the point. The program is UB the moment you add a non-zero displacement to nullptr. UB can manifest in many different ways, including "behaving exactly as you'd expect" (for any definition of "you" and "expect"). The most likely scenario is that the compiler will emit an addition and result in a small pointer value around 0x0. But you can't count on it. In an ASan build, for example, the compiler might have already inserted an escape path that aborts the execution (https://godbolt.org/z/q84nEaxTT). -- 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] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals