Re: [libvirt] [PATCH v2 13/14] nodedev: Pass @def by reference to create/assign object
On 05/26/2017 08:12 AM, Peter Krempa wrote:
On Thu, May 25, 2017 at 15:57:10 -0400, John Ferlan wrote:
> Since the @def is consumed by the assignment function, let's pass by
> reference instead of value and really consume it.
>
> Signed-off-by: John Ferlan <jferlan(a)redhat.com>
> ---
> src/conf/virnodedeviceobj.c | 8 ++++----
> src/conf/virnodedeviceobj.h | 2 +-
> src/node_device/node_device_hal.c | 2 +-
> src/node_device/node_device_udev.c | 8 +++-----
> src/test/test_driver.c | 5 ++---
> 5 files changed, 11 insertions(+), 14 deletions(-)
>
> diff --git a/src/conf/virnodedeviceobj.c b/src/conf/virnodedeviceobj.c
> index a7e51ef..1648b33 100644
> --- a/src/conf/virnodedeviceobj.c
> +++ b/src/conf/virnodedeviceobj.c
> @@ -268,13 +268,13 @@ virNodeDeviceObjListFree(virNodeDeviceObjListPtr devs)
>
> virNodeDeviceObjPtr
> virNodeDeviceObjAssignDef(virNodeDeviceObjListPtr devs,
> - virNodeDeviceDefPtr def)
> + virNodeDeviceDefPtr *def)
I don't really like this. You can documment that this function either
consumes def always or only on success and the callers can free the
pointer. Passing the pointer to a pointer just to clear it in some cases
is overcomplicating stuff.
True, but I ran into in one case (I forget which one now) where the
assumption was that the @def wasn't consumed on a failure, but in
reality it had been. The obj->def got assigned, then the attempt was
made to add the obj to the list which if it failed would call whatever
cleanup routine was there which free'd @obj->def and returned to the
caller with a failure which would attempt to free @def (again). My first
instinct was to just set obj->def = NULL prior to the cleanup, which
worked for a short time until obj->def was a "real" object and the
cleanup code didn't own obj any more.
So it's the long winded way of saying - I can drop this and the
following patch either be "more careful" as necessary or just claim at
some point in time that @def would be consumed on both success and
failure, which I think follows how virJSONValueObjectCreate eats the
"a:" arguments (and causes many false positives for Coverity).
John