I'm not say it catches everything, only that NULL+-MAX_INVALID_ADDRESS
get's treated as invalid at all times so that at the very least, regardless
of where a pointer comes from (since c++ is not in a bubble no matter how
much it wants to be) it has a baseline standard of what cannot possibly be
a valid pointer, and NULL+-index is a common bug that slips through
sometimes, mostly due to a fault in logic that is supposed to sanity check
the pointer correctly.

On Thu, 31 Jul 2025 at 17:59, Sebastian Wittmeier via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> 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]> 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 - thiago (AT) kde.org
> Principal Engineer - Intel Platform & System Engineering
>
>
>
> --
> 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
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>