Date: Fri, 25 Jul 2025 12:43:19 -0400
> Sorry, not so.
It might not be an allocated object but 0 (zero) can be a valid address.
On some platforms it is the reset/interrupt vector.
No, a pointer object initialized from "nullptr", "0", or "NULL" (which must be either "nullptr" or "0") yields the null pointer value of its type and this value never points to an object. Even if the OS maps something at that address (interrupt vector or whatever), that entity is not accessible from within a conforming C++ program (and ideally the current process has no read and no write permission to the page for that address, which normally leads to segfault if the compiler did not optimized away the UB).
<https://cppreference.com/w/cpp/language/pointer.html#Null_pointers>
If you read the standard carefully, initialization of a pointer type with a constant "nullptr", "0" or "NULL" is required to point at a location that has no object, furthermore this location need not even be located at address "0x0", the actual value representation of the null pointer value of T* is unspecified, and also irrelevant. Even the following is unspecified (could be true or false)
"(void*)nullptr != reinterpret_cast<void*>(0x0)"
On July 25, 2025 11:14:24 a.m. EDT, Chris Ryan via Std-Proposals <std-proposals_at_[hidden]> wrote:
>> There is only one pointer value that is guaranteed to not point at
>any object, and that's nullptr.
>Sorry, not so.
>
>It might not be an allocated object but 0 (zero) can be a valid address.
>On some platforms it is the reset/interrupt vector.
>
>On Fri, Jul 25, 2025 at 5:03 AM Andrey Semashev via Std-Proposals <
>std-proposals_at_[hidden]> wrote:
>
>> On 25 Jul 2025 14:17, Frederick Virchanza Gotham via Std-Proposals wrote:
>> > I'm writing some code at the moment, and the destructor looks like this:
>> >
>> > ~Governor(void) noexcept
>> > {
>> > try
>> > {
>> > delete this->p;
>> > }
>> > catch(...){}
>> >
>> > this->p = (void*)0xdeadbeef;
>> > }
>> >
>> > I've set the pointer to 0xdeadbeef because I want to make sure that
>> > there's nowhere else in the code that this particular object gets
>> > deleted. If another part of the code goes to delete the object a
>> > second time, it will segfault on 0xdeadbeef -- which is exactly what I
>> > want to happen because I want the debugger to catch it.
>>
>> And what if 0xdeadbeef is a valid pointer?
>>
>> Even if it's not, you're not guaranteed to get a crash either. You may
>> get a corrupted heap and continue running with garbage data in your
>> memory, and undefined outcome.
>>
>> There is only one pointer value that is guaranteed to not point at any
>> object, and that's nullptr. If you want to add another one, that would
>> have to go beyond just defining a new constant. The whole runtime
>> (including but not limited to the memory allocator) would have to be
>> updated with support for this new constant.
>>
>> You can also create "invalid" pointer values yourself, which are "safe"
>> to a certain degree. For example:
>>
>> void* make_invalid_ptr()
>> {
>> // Mark it const so that it is hopefully placed in a read-only
>> // memory region, which would prevent modifications by the
>> // memory allocator. Also make it large enough so that the
>> // allocator doesn't corrupt neighbouring data.
>> static const unsigned char dummy[PAGE_SIZE] = {};
>> return dummy + PAGE_SIZE / 2;
>> }
>>
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
It might not be an allocated object but 0 (zero) can be a valid address.
On some platforms it is the reset/interrupt vector.
No, a pointer object initialized from "nullptr", "0", or "NULL" (which must be either "nullptr" or "0") yields the null pointer value of its type and this value never points to an object. Even if the OS maps something at that address (interrupt vector or whatever), that entity is not accessible from within a conforming C++ program (and ideally the current process has no read and no write permission to the page for that address, which normally leads to segfault if the compiler did not optimized away the UB).
<https://cppreference.com/w/cpp/language/pointer.html#Null_pointers>
If you read the standard carefully, initialization of a pointer type with a constant "nullptr", "0" or "NULL" is required to point at a location that has no object, furthermore this location need not even be located at address "0x0", the actual value representation of the null pointer value of T* is unspecified, and also irrelevant. Even the following is unspecified (could be true or false)
"(void*)nullptr != reinterpret_cast<void*>(0x0)"
On July 25, 2025 11:14:24 a.m. EDT, Chris Ryan via Std-Proposals <std-proposals_at_[hidden]> wrote:
>> There is only one pointer value that is guaranteed to not point at
>any object, and that's nullptr.
>Sorry, not so.
>
>It might not be an allocated object but 0 (zero) can be a valid address.
>On some platforms it is the reset/interrupt vector.
>
>On Fri, Jul 25, 2025 at 5:03 AM Andrey Semashev via Std-Proposals <
>std-proposals_at_[hidden]> wrote:
>
>> On 25 Jul 2025 14:17, Frederick Virchanza Gotham via Std-Proposals wrote:
>> > I'm writing some code at the moment, and the destructor looks like this:
>> >
>> > ~Governor(void) noexcept
>> > {
>> > try
>> > {
>> > delete this->p;
>> > }
>> > catch(...){}
>> >
>> > this->p = (void*)0xdeadbeef;
>> > }
>> >
>> > I've set the pointer to 0xdeadbeef because I want to make sure that
>> > there's nowhere else in the code that this particular object gets
>> > deleted. If another part of the code goes to delete the object a
>> > second time, it will segfault on 0xdeadbeef -- which is exactly what I
>> > want to happen because I want the debugger to catch it.
>>
>> And what if 0xdeadbeef is a valid pointer?
>>
>> Even if it's not, you're not guaranteed to get a crash either. You may
>> get a corrupted heap and continue running with garbage data in your
>> memory, and undefined outcome.
>>
>> There is only one pointer value that is guaranteed to not point at any
>> object, and that's nullptr. If you want to add another one, that would
>> have to go beyond just defining a new constant. The whole runtime
>> (including but not limited to the memory allocator) would have to be
>> updated with support for this new constant.
>>
>> You can also create "invalid" pointer values yourself, which are "safe"
>> to a certain degree. For example:
>>
>> void* make_invalid_ptr()
>> {
>> // Mark it const so that it is hopefully placed in a read-only
>> // memory region, which would prevent modifications by the
>> // memory allocator. Also make it large enough so that the
>> // allocator doesn't corrupt neighbouring data.
>> static const unsigned char dummy[PAGE_SIZE] = {};
>> return dummy + PAGE_SIZE / 2;
>> }
>>
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
Received on 2025-07-25 16:43:59