You are over thinking this.

Everywhere an invalid pointer is just null == 0, even if all addresses are valid.

Unless you are a part of the system that intentionally aims to read/write to that piece of the table (which explicitly knows about what's at that address), then that pointer is not for you.

There's nothing that says an application must segfault, I see no reason why you couldn't write an application in C++ where all of the memory is valid and accessible and that it could do absolutely whatever and never stop running. It may be running invalid code, but it is a computer that you can build.
UB is UB, it's not a bug, it's a feature, so that you can actually do things in practice.

0xdeadbeef or any modification of it is a bad idea, it assumes too much and it tries to create a problem that already had a solution.
You can move on, there's nothing else to see here.


________________________________
From: Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf of Frederick Virchanza Gotham via Std-Proposals <std-proposals_at_[hidden]>
Sent: Sunday, August 3, 2025 5:49:22 AM
To: std-proposals_at_[hidden] <std-proposals_at_[hidden]>
Cc: Frederick Virchanza Gotham <cauldwell.thomas_at_[hidden]>
Subject: Re: [std-proposals] Standardising 0xdeadbeef for pointers



On Saturday, August 2, 2025, David Brown wrote:


There are microcontrollers supporting C++ with 16-bit pointers where there are /no/ invalid pointers - all are valid.



I think we should be focusing on this example for a minute.

So let's say we have a Harvard Architecture microcontroller, with code memory (non-volatile) separate from data memory (volatile), and let's say it has 65 kilobytes of SRAM.

If address 0 is accessible in the SRAM, then there's three viable strategies:
(1) Make nullptr == 0xffff
(2) Make nullptr == 0xfffe
(3) Make nullptr == 0x0000, but before any pointer is dereferenced, subtract 1 from it.

With strategy No. 3, a pointer would have the bit pattern 0x0001 in order to access address 0.

Next question then is: If you want to identify the last byte as a range, i.e. [begin,end) , then will the end pointer be the same as the nullptr? If this must be avoided then it seems like 1 byte in the SRAM must be inaccessible from the C++ programming language. Unless it were to be stipulated that the end pointer might be equal to a null pointer.

And then what happens if we introduce badptr? Will badptr be given the bit pattern 0xFFFF? Subtracting 1 from it would give 0xFFFE -- but maybe that subtraction should never take place if the operand is 0xFFFF.