Date: Thu, 31 Jul 2025 17:14:52 +0000
What I would prefer is a function that would be able to tell if an address is accessible instead of relying on magic numbers.
If you want to solve the problem, solve the problem.
And to be fair if you are still using 'snprintf' you are not taking code safety seriously. There's no need to make pointers more complex or force me to test more than if(ptr == nullptr) in order to decide if the pointer is intended to be invalid.
Don't make writing correct code harder under the gaze of "making code safer" when that code is inherently unsafe and should have been deprecated a long time ago.
________________________________
From: zxuiji <gb2985_at_[hidden]>
Sent: Thursday, July 31, 2025 6:58:37 PM
To: Tiago Freire <tmiguelf_at_[hidden]>
Cc: std-proposals_at_[hidden] <std-proposals_at_[hidden]>
Subject: Re: [std-proposals] Standardising 0xdeadbeef for pointers
On Thu, 31 Jul 2025 at 17:51, Tiago Freire <tmiguelf_at_[hidden]<mailto: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]<mailto: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]<mailto:std-proposals-bounces_at_[hidden]>> on behalf of zxuiji via Std-Proposals <std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>>
Sent: Thursday, July 31, 2025 6:46:39 PM
To: std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]> <std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>>
Cc: zxuiji <gb2985_at_[hidden]<mailto: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).
If you want to solve the problem, solve the problem.
And to be fair if you are still using 'snprintf' you are not taking code safety seriously. There's no need to make pointers more complex or force me to test more than if(ptr == nullptr) in order to decide if the pointer is intended to be invalid.
Don't make writing correct code harder under the gaze of "making code safer" when that code is inherently unsafe and should have been deprecated a long time ago.
________________________________
From: zxuiji <gb2985_at_[hidden]>
Sent: Thursday, July 31, 2025 6:58:37 PM
To: Tiago Freire <tmiguelf_at_[hidden]>
Cc: std-proposals_at_[hidden] <std-proposals_at_[hidden]>
Subject: Re: [std-proposals] Standardising 0xdeadbeef for pointers
On Thu, 31 Jul 2025 at 17:51, Tiago Freire <tmiguelf_at_[hidden]<mailto: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]<mailto: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]<mailto:std-proposals-bounces_at_[hidden]>> on behalf of zxuiji via Std-Proposals <std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>>
Sent: Thursday, July 31, 2025 6:46:39 PM
To: std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]> <std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>>
Cc: zxuiji <gb2985_at_[hidden]<mailto: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 17:14:56