BTW, I will note that there is at least one more invalid address (The Rust
Project figured this out, as well as the proof), but it's the address
immediately before the null pointer: 0xFF...FF with nullptr=0. We can prove
this is invalid for size 1 objects because every object has a valid
1-past-the end pointer, and this pointer cannot compare equal to the null
pointer. We can prove this invalid for larger objects, because it would
require an element of the object representation (also generally an object
of align N cannot overlap the address -(uintptr_t)N for the same reason,
and an object of size N cannot start at address -N). However, if the goal
is an address that is guaranteed to crash on access (or more generally, is
EB to access through, rather than UB), then I guarantee you optimized
compilers will be annoyed. I know at the very least llvm considers all
normal reads and writes to be willreturn, and move other options passed
them.

On Sat, Jul 26, 2025 at 16:19 Sebastian Wittmeier via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> When the lifetime of the Governor project ends, reading it is _not_ only
> problematic for pointer members:
>
>
>
> If you read an `int`, whether it is an opaque handler or an index or a
> scale factor, it is already wrong.
>
> So with 0xdeadbeef you would only detect a small number of cases for that
> specific error of your given example.
>
> The actual error happens beforehand.
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>