> On Jul 25, 2025, at 5:19 AM, Frederick Virchanza Gotham via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> On Fri, Jul 25, 2025 at 1:03 PM Andrey Semashev wrote:
>>
>> 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.
>
>
> Not really. There isn't a computer in existence today -- I don't think
> -- that uses more than 49 bits for a memory address. 64-Bit ARM uses
> 48 bits but it can be extended by 1 bit to 49 bits.
>
> So you can mark a pointer as 'bad' by manipulating the top 15 bits. Or
> even just set the top bit high.

This is nonsense.

High bits are 100% valid on numerous platforms.

Numerous platforms make use of the high bits: CHERI, ARMv8.3 with PAC extensions, MTE, etc

In addition to that many OS’s use high bits in kernel addresses. e.g 0x111….. is kernel space, 0x0000…. is user space.

>> 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;
>> }
>
>
> Not a bad idea. So internally the compiler would do something like:
>
> constexpr unsigned PAGE_SIZE = 1024u;

Nit: getpagesize() - though that’s not a constexpr

> Then whenever a pointer is dereferenced when NDEBUG is undefined, the
> compiler checks if the pointer points inside badptr_t::dummy.

If you want an guaranteed invalid address, just allocate one using standard APIs.

Checking for a pointer to your definitionally non-invalid address means it will be valid in literally all code you do not control.

Please stop spamming the list with these “proposals” without doing some actual background research, and providing a paper that enumerates the existing work, and potential problems.

It is unfair for you to essentially demand time from others in the committee when you yourself are not putting the work in.

—Oliver