Re: Should functions that free memory clear the pointer?

["Cédric Le Goater" <clg@redhat.com>]

On 11/26/25 07:12, Markus Armbruster wrote:
> 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'm not a big fan of g_clear_pointer() either; I prefer being explicit,
even if it means a bit of redundancy.


Thanks,

C.



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