From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49805) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vm1xT-0005Nf-FV for qemu-devel@nongnu.org; Thu, 28 Nov 2013 08:48:48 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vm1xI-0001II-Ih for qemu-devel@nongnu.org; Thu, 28 Nov 2013 08:48:43 -0500 Received: from mx1.redhat.com ([209.132.183.28]:26994) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vm1xI-0001Gy-9o for qemu-devel@nongnu.org; Thu, 28 Nov 2013 08:48:32 -0500 Date: Thu, 28 Nov 2013 14:48:22 +0100 From: Igor Mammedov Message-ID: <20131128144822.3d0f8e82@nial.usersys.redhat.com> In-Reply-To: <5297484E.5080105@suse.de> References: <1385601858-8065-1-git-send-email-imammedo@redhat.com> <5297484E.5080105@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH] qom: abort on error in property setter if caller passed errp == NULL List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Andreas =?ISO-8859-1?B?RuRyYmVy?= Cc: Peter Maydell , peter.crosthwaite@xilinx.com, mst@redhat.com, qemu-devel@nongnu.org, Markus Armbruster , anthony@codemonkey.ws, pbonzini@redhat.com On Thu, 28 Nov 2013 14:42:38 +0100 Andreas F=E4rber wrote: > Am 28.11.2013 02:24, schrieb Igor Mammedov: > > in case if caller setting property doesn't care about error and > > passes in NULL as errp argument but error occurs in property setter, > > it is silently discarded leaving object in undefined state. > >=20 > > As result it leads to hard to find bugs, so if caller doesn't > > care about error it must be sure that property exists and > > accepts provided value, otherwise it's better to abort early > > since error case couldn't be handled gracefully and find > > invalid usecase early. > >=20 > > In addition multitude of property setters will be always > > guarantied to have error object present and won't be required > > to handle this condition individually. > >=20 > > Signed-off-by: Igor Mammedov > > --- > > qom/object.c | 19 ++++++++++++++----- > > 1 file changed, 14 insertions(+), 5 deletions(-) > >=20 > > diff --git a/qom/object.c b/qom/object.c > > index fc19cf6..2c0bb64 100644 > > --- a/qom/object.c > > +++ b/qom/object.c > > @@ -792,16 +792,25 @@ void object_property_get(Object *obj, Visitor *v,= const char *name, > > void object_property_set(Object *obj, Visitor *v, const char *name, > > Error **errp) > > { > > - ObjectProperty *prop =3D object_property_find(obj, name, errp); > > - if (prop =3D=3D NULL) { > > - return; > > + Error *local_error =3D NULL; > > + ObjectProperty *prop =3D object_property_find(obj, name, &local_er= ror); > > + if (local_error) { > > + goto out; > > } > > =20 > > if (!prop->set) { > > - error_set(errp, QERR_PERMISSION_DENIED); > > + error_set(&local_error, QERR_PERMISSION_DENIED); > > } else { > > - prop->set(obj, v, prop->opaque, name, errp); > > + prop->set(obj, v, prop->opaque, name, &local_error); > > } > > +out: > > + if (local_error) { > > + if (!errp) { > > + assert_no_error(local_error); > > + } > > + error_propagate(errp, local_error); > > + } > > + > > } > > =20 > > void object_property_set_str(Object *obj, const char *value, >=20 > Aborting on NULL errp considered dangerous by me. >=20 > This function seems to work just fine with NULL errp, so your focus > seems to be on the callers. >=20 > Promoting *not* to abort has been one appeal of the new QOM-style APIs > to me, so making this implicitly assert feels like a step backwards. > The old qdev_prop_set_*() API, which most users are still using, does > assert, as discussed with PMM recently. >=20 > Also, why only for setting properties? Either all or none should behave > like this - and I guess none is going to be easier to achieve. > For instance, adding dynamic properties is a use case where in > instance_init I've seen NULL errp passed in (because instance_init API > cannot fail). >=20 > I will be more than happy to review and apply your patch (or contribute > further ones) going through (mis)uses of error_is_set(). I've sent such one for target-i386/cpu.c see last patch in x86-properties.v= 10, I've posted today. >=20 > Regards, > Andreas >=20