The problem with this proposal, I think, is that it's based on an incorrect premise. Use-after-free is not a bug in itself, it is a symptom. If all pointers to the invalid location were poisoned, that would solve nothing, it would only change the symptom to dereferencing a poisoned pointer. We can't solve deep semantic problems with slight tweaks: resource ownership is deeply meaningful, it's an evil fallacy that it can be brushed away as a minor detail. If resource users neglect to explicitly sincronize with the owner when running asynchronously, if there's no awareness of the roles of each of them, that's a very serious bug.

On the value of swapping symptoms: I completely agree that an immediate hard failure is much better than the completely unpredictable nature of using invalid memory, but there's a trade-off with runtime cost, and, if we're willing to pay with runtime performance, sanitised builds are incredibly more useful.


On Sat, 23 Aug 2025, 10:31 Jonathan Wakely via Std-Proposals, <std-proposals@lists.isocpp.org> wrote:


On Sat, 23 Aug 2025, 10:20 organicoman, <organicoman@yahoo.fr> wrote:



Use after free, double free...etc will be more like to be caught in code
{
  m_ptr = new T;

  // if all the following take m_ptr by reference 
  inspect_maybe_free(m_ptr);
  transform_maybe_free(m_ptr);
  maybe_free(m_ptr);

  // i can detect if delete was called before.
  if(m_ptr) delete m_ptr;
}

With the current implementation,  you cannot do this.

 This is in practice what I would consider an actual trivial UaF, because straight line examples you’ve presented are so easily automatically detected and presented.

I don't see how my example is a trivial straight line UaF or double free.
Given the current implementation of delete,
If you pass the pointer by copy, when you return back to the caller, nothing can tell if the resource was freed inside the callees.
If you pass by reference,  you have to zero out the pointer manually in the callee scope (error prone).

So stop using raw pointers like this then. 


So, for an analyzer, it cannot tell what happens inside the callees unless it traverses all the calling tree, inside each callee...., and that is not trivial!

But your suggestion of a compiler flag, would do the job I guess.

--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals