Date: Thu, 31 Jul 2025 18:12:41 +0100
On Thu, 31 Jul 2025 at 17:51, Tiago Freire <tmiguelf_at_[hidden]> wrote:
> I thought this topic was pretty much dead.
>
Lol, love the joke XD
On Thu, 31 Jul 2025 at 17:51, Tiago Freire <tmiguelf_at_[hidden]> wrote:
> 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?
>
I already gave example before but I understand the desire not to go
hunting through the emails so I'll repeat myself. It's for library
functions, be it from stdlib; boost or some other library, like snprintf to
give an optional garauntee that if an address lands in said range (like
from an unchecked pointer having pointer arithmetic applied with something
like head + index) then instead of allowing the resulting segfault to occur
it will instead just set errno to EADDRESSNOTAVAILABLE or something and
return -1, that in turn allows a developer to tell snprintf to do exactly
that so they can put it in their server log or game crash report or
similar so they can potentially know to look for it before a hacker learns
of the exploitable bug.
------------------------------
*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]> 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).
> I thought this topic was pretty much dead.
>
Lol, love the joke XD
On Thu, 31 Jul 2025 at 17:51, Tiago Freire <tmiguelf_at_[hidden]> wrote:
> 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?
>
I already gave example before but I understand the desire not to go
hunting through the emails so I'll repeat myself. It's for library
functions, be it from stdlib; boost or some other library, like snprintf to
give an optional garauntee that if an address lands in said range (like
from an unchecked pointer having pointer arithmetic applied with something
like head + index) then instead of allowing the resulting segfault to occur
it will instead just set errno to EADDRESSNOTAVAILABLE or something and
return -1, that in turn allows a developer to tell snprintf to do exactly
that so they can put it in their server log or game crash report or
similar so they can potentially know to look for it before a hacker learns
of the exploitable bug.
------------------------------
*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]> 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:58:38