Is there any _standard_ reason, why this could not happen with volatile, too? There is no other volatile operation before the destruction.   -----Ursprüngliche Nachricht----- Von:Frederick Virchanza Gotham via Std-Proposals <std-proposals_at_[hidden]> Gesendet:So 27.07.2025 20:29 Betreff:Re: [std-proposals] Standardising 0xdeadbeef for pointers An:std-proposals_at_[hidden]; CC:Frederick Virchanza Gotham <cauldwell.thomas_at_[hidden]>; 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'). -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals