qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v2 0/3] require newer glib2 to enable autofree'i


From: Alex Bennée
Subject: Re: [Qemu-devel] [PATCH v2 0/3] require newer glib2 to enable autofree'ing of stack variables exiting scope
Date: Wed, 31 Jul 2019 15:33:22 +0100
User-agent: mu4e 1.3.3; emacs 27.0.50

Daniel P. Berrangé <address@hidden> writes:

> On Wed, Jul 31, 2019 at 03:04:29PM +0100, Alex Bennée wrote:
>>
>> Daniel P. Berrangé <address@hidden> writes:
>>
>> > Both GCC and CLang support a C extension attribute((cleanup)) which
>> > allows you to define a function that is invoked when a stack variable
>> > exits scope. This typically used to free the memory allocated to it,
>> > though you're not restricted to this. For example it could be used to
>> > unlock a mutex.
>> <snip>
>> >
>> >     GOOD:
>> >         g_autofree char *wibble = g_strdup("wibble")
>> >    ...
>> >    return g_steal_pointer(wibble);
>> >
>> >     g_steal_pointer is an inline function which simply copies
>> >     the pointer to a new variable, and sets the original variable
>> >     to NULL, thus avoiding cleanup.
>>
>> Surely this is a particular use case where you wouldn't use g_autofree
>> to declare the variable as you intending to return it to the outer scope?
>
> I think it depends on the situation. Obviously real code will have
> something in the "..." part I snipped.
>
> You have 20 code paths that can result in returning with an error, where
> you want to have all variables freed, and only 1 code path for success
> Then it makes sense to use g_autofree + g_steal_pointer to eliminate
> many goto jumps.
>
> If you have only 1 error path and 1 success path, then a traditional
> g_free() call is may well be sufficient.

I suspect this would be worth a write up in HACKING or CODING_STYLE with
the next iteration? (which reminds me we should really merge and .rst up
those documents)

>
> IOW, as with many coding "rules", there's scope to use personal
> judgement as to when it is right to ignore it vs folow it.
>
> Regards,
> Daniel


--
Alex Bennée



reply via email to

[Prev in Thread] Current Thread [Next in Thread]