Should functions that free memory clear the pointer? (was: [PATCH] migration: Fix double-free on error path)

[Markus Armbruster <armbru@redhat.com>]

Peter Xu <peterx@redhat.com> writes:

> On Tue, Nov 25, 2025 at 07:48:44PM +0100, Markus Armbruster wrote:
>> My main argument remains this one: our deallocating functions don't work
>> that way.  For better or worse.
>> 
>> I don't want the Error API free differently.
>
> Yes, it's fair.
>
> IMHO, it's a matter of taste,

Depends on context.

Modula-2's DISPOSE takes the pointer by reference and clears it.  C's
free() takes it by value.  Matter of taste when these were designed.

But when one style has become overwhelmingly prevalent, it's no longer a
matter of taste.  This is arguably the case in C.

>                               and maybe that's also why I liked
> g_clear_pointer() but not everyone likes it.. said that, when we have
> g_clear_pointer() it also makes the current form more flexible, because we
> can apply g_clear_pointer() on top when we need a reset..

I'm no friend of g_clear_pointer().  I find

    g_clear_pointer(&ptr, free_frob);

a rather roundabout way to say

    free_frob(ptr);
    ptr = NULL;

Any C programmer will immediately understand the latter.  For the
former, you need to know one more little thing.  Yes, we can all get
used to these little things, but it's one more little thing new people
have to learn and internalize.  Even little things add up.

If an entire project gets into the habit of using it religiously, it may
reduce "forgot to zap the reference" bugs some.  Until then, it feels
like a net negative to me.

> I'll follow your advise on error reporting for migration.

Thank you!