Uh, what is wrong with NULL? Nobody expects a pointer to be below
sysconf(SC_PAGE_SIZE) so regardless of if the pointer is incremented or not
one would recognise it as an invalid pointer while debugging.

On Mon, 28 Jul 2025 at 10:58, David Brown via Std-Proposals <
std-proposals_at_[hidden]> wrote:

>
>
> On 27/07/2025 20:29, Frederick Virchanza Gotham via Std-Proposals wrote:
> > On Sun, Jul 27, 2025 at 2:11 AM Breno Guimarães wrote:
> >>
> >> Compile with -O2 and you will see that it prints 0
> >
> >
> > Just to clarify what's going on here . . . When the compiler
> > encounters the assignment to "p" in the destructor, it sees that the
> > variable "p" isn't read from again before "*this" is destroyed, so the
> > assignment is optimised away. You can disable the optimisation by
> > changing the following line:
> >
> > p = . . . .
> >
> > into:
> >
> > const_cast<decltype(p) volatile &>(p) = . . . .
> >
> > Of course this doesn't change the fact that the C++26 Standard says
> > that an object's bytes are unspecified after the object dies, but
> > still it keeps us sane to understand why the compiler's doing what
> > it's doing.
> >
> > So far I think David Brown's idea is the best, he wrote:
> >
> > > const int deadbeaf { };
> > > const void * badptr { &deadbeaf };
> >
> > > Then when you start your debugger, put a data watchpoint
> (read/write
> > > access) on the symbol "deadbeaf". Any time your code tries to
> access
> > > that address, your debugger halts the code.
> >
> >
> > I think David's idea, combined with Address Sanitizer, would be a
> > winner, because it would also catch instances where the address of
> > 'badptr' is incremented and dereferenced. It might be an idea to
> > "build this into" the compiler and debugger, and to standardise the
> > nomenclature in the C++ standard (i.e. 'badptr_t' and 'badptr').
>
> If you think it is realistic that the contents of the "badptr" variable
> itself is changed, then put another data watchpoint on that variable.
> That will catch more than just incrementation. But I would be surprised
> to see a compiler make "badptr" as a variable - compilers, at least when
> optimising, will treat it like "&deadbeaf" directly in the code. (And
> you can just add another "const" to the declaration of badptr to catch
> code errors.)
>
> gcc/clang address sanitiser, along with other run-time memory error
> detection systems, are certainly useful tools, and probably worth using
> for catching your bugs. But if you are running under a debugger, data
> watchpoints are less intrusive.
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>