Date: Thu, 31 Jul 2025 18:00:36 +0100
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
>
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
>
Received on 2025-07-31 16:46:34