[libvirt] [PATCH 1/1] admin_server: use VIR_AUTOFREE() in adminClientGetInfo string

Daniel Henrique Barboza danielhb413 at gmail.com
Tue Oct 1 15:04:53 UTC 2019



On 10/1/19 11:54 AM, Daniel P. Berrangé wrote:
> On Tue, Oct 01, 2019 at 11:49:25AM -0300, Daniel Henrique Barboza wrote:
>>
>> On 10/1/19 11:25 AM, Ján Tomko wrote:
>>> On Tue, Oct 01, 2019 at 03:59:07PM +0200, Erik Skultety wrote:
>>>> On Tue, Oct 01, 2019 at 09:12:58AM -0300, Daniel Henrique Barboza wrote:
>>>>> Signed-off-by: Daniel Henrique Barboza <danielhb413 at gmail.com>
>>>>> ---
>>>> Reviewed-by: Erik Skultety <eskultet at redhat.com>
>>>>
>>>> and safe for freeze
>>>>
>>> This is not a bugfix, it can wait.
>>>
>>> Also, there is an ongoing discussion about using g_autofree once we
>>> start depending on gnulib, so I don't see a point in trying to convert
>>> code to the macro that will soon be obsolete.
>> Huh. Guess I'll stop sending those VIR_AUTO* patches all around then. I'll
>> wait for the gnulib equivalent, if there will be any.
> NB, glib != gnulib :-)

I went with 'gnulib' following up the email from Jano! Not sure now if
he was speaking about the POSIX layer or not, but I'm pinning my
shame on him!

:)

>
> gnulib is the POSIX portability layer we're trying to eliminate.
>
> glib is the higher level library we're trying to adopt.
>
> The new approach will be more or less identical just different
> naming convention.
>
> I'll get my current glib series in a working state again and
> push it somewhere public. That would enable you to base your
> work on top of the glib series, using the new glib macros,
> so that you're not blocked.

I appreciate that, but feel free to take your time. I'm working in other
things that are unrelated to these cleanups.

As soon as your patch set hits upstream (or you make the patches public)
I can simply re-send all the patches changing VIR_AUTO* with the
glib equivalent.


Thanks,


DHB

>
> Regards,
> Daniel




More information about the libvir-list mailing list