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@xxxxxxxxxx> >> --- >> 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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
