Date: Thu, 31 Jul 2025 16:51:55 +0000
I thought this topic was pretty much dead.
UB is UB.
Yeah, you could probably do X, Y, or Z, but why make things more difficult than what they need to be? Why do you want to do this? What's the motivation beyond academic curiosity?
________________________________
From: Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf of zxuiji via Std-Proposals <std-proposals_at_[hidden]>
Sent: Thursday, July 31, 2025 6:46:39 PM
To: std-proposals_at_[hidden] <std-proposals_at_[hidden]>
Cc: zxuiji <gb2985_at_[hidden]>
Subject: Re: [std-proposals] Standardising 0xdeadbeef for pointers
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).
UB is UB.
Yeah, you could probably do X, Y, or Z, but why make things more difficult than what they need to be? Why do you want to do this? What's the motivation beyond academic curiosity?
________________________________
From: Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf of zxuiji via Std-Proposals <std-proposals_at_[hidden]>
Sent: Thursday, July 31, 2025 6:46:39 PM
To: std-proposals_at_[hidden] <std-proposals_at_[hidden]>
Cc: zxuiji <gb2985_at_[hidden]>
Subject: Re: [std-proposals] Standardising 0xdeadbeef for pointers
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
Received on 2025-07-31 16:52:02