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_at_[hidden]> wrote:

>
>
> On Sat, 23 Aug 2025, 10:20 organicoman, <organicoman_at_[hidden]> 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_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>