> On Aug 24, 2025, at 2:53 PM, organicoman via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> Ok, let me illustrate with a silly example:
> 1- let's take the current state of the 'delete expression as par the current pre-conditions, i.e, it doesn’t take by reference, and it doesn't null its argument.
>
> Expl:
> ----- begin snippet----
> {
> T* p = new T;
> Dll_fn_takes_by_Copy (p);
> delete p;
> }
> /// somwhere in a dll library
> void Dll_fn_takes_by_Copy(T* pt)
> {
> T* ptr = new T;
> // use ptr, and pt
> delete pt;
> }
> ----- end snippet-----
>
> The dll source is inaccessible to me, or my static analyzer.
>
> Can you catch the bug?
>
> I am pretty sure you did.
>
> Instead of deleting 'ptr', the dll deleted 'pt'.
> Just one character missed unintentionally.
>
> How can I guess, what happened in my code?
> Especially if the dll documentation says explicitly that they don't delete the passed pointer.
>
> I fall in double free bug.
>
> Now take the same example with the proposal.i.e. the delete expression takes a reference argument, and nulls out it + the guideline pass by reference.
>
> ----- begin snippet----
> {
> T* p = new T;
> Dll_fn_takes_by_ref (p);
> if(p)
> delete p;
> }
> /// somwhere in a dll library
> void Dll_fn_takes_by_ref(T* &pt)
> {
> T* ptr = new T;
> // use ptr, and pt
> delete pt;
> }
> ----- end snippet-----
>
> Here no matter what unintentional error happens in the dll, I can safe guard against it.
>
> Is my example clear?

The new code you are proposing is the one that hides a bug. For the first version of the code you said that the DLL function deletes the wrong pointer. In the new version this bug is still there. I prefer to have a double free error at runtime (which is worse than a compile error) instead of a hidden bug.

I suggest you start following the C++ core guideline: No owning raw pointers! This would mean that both functions get smart pointers (but the argument to the DLL function is still a raw pointers because it is non-owning). You don’t have to call delete and smart pointers are automatically nullified. A static analyzer can check that raw pointers are always non-owning. This means you are never allowed to call delete on a raw pointer. A static analyzer can check this. The actual bug you are describing for your DLL function would be impossible with a static analyzer that checks the core guidelines (as far as checks can be done).
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals