[...]
>>> the comments further onward would be simply the same, you get the picture,
>>> but
>>> those are just tiny nitpicks based on personal preference I'd say (except
>>> for
>>> copying the same error messages all over again), with that addressed:
>>
>> Nope, the picture wasn't clear, but
On Fri, Sep 21, 2018 at 07:46:47AM -0400, John Ferlan wrote:
>
>
> On 09/21/2018 04:43 AM, Erik Skultety wrote:
> > On Thu, Sep 20, 2018 at 05:34:37PM -0400, John Ferlan wrote:
> >> Commit 40b5c99a modified the virConfGetValue callers to use
> >> virConfGetValueString. However, using the virConfGet
On 09/21/2018 04:43 AM, Erik Skultety wrote:
> On Thu, Sep 20, 2018 at 05:34:37PM -0400, John Ferlan wrote:
>> Commit 40b5c99a modified the virConfGetValue callers to use
>> virConfGetValueString. However, using the virConfGetValueString
>> resulted in leaking the returned @value string in each
On Thu, Sep 20, 2018 at 05:34:37PM -0400, John Ferlan wrote:
> Commit 40b5c99a modified the virConfGetValue callers to use
> virConfGetValueString. However, using the virConfGetValueString
> resulted in leaking the returned @value string in each case.
> So, let's modify each instance to use the VIR
Commit 40b5c99a modified the virConfGetValue callers to use
virConfGetValueString. However, using the virConfGetValueString
resulted in leaking the returned @value string in each case.
So, let's modify each instance to use the VIR_AUTOFREE(char *)
syntax. In some instances changing the variable nam