From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60806) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zg1fj-0005x9-NU for qemu-devel@nongnu.org; Sat, 26 Sep 2015 22:26:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zg1fg-0000OX-GJ for qemu-devel@nongnu.org; Sat, 26 Sep 2015 22:26:39 -0400 Received: from mx1.redhat.com ([209.132.183.28]:56572) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zg1fg-0000ON-9L for qemu-devel@nongnu.org; Sat, 26 Sep 2015 22:26:36 -0400 References: <1442872682-6523-1-git-send-email-eblake@redhat.com> <1442872682-6523-8-git-send-email-eblake@redhat.com> <87r3lneuet.fsf@blackfin.pond.sub.org> <560710F4.40003@redhat.com> From: Eric Blake Message-ID: <560753D4.10204@redhat.com> Date: Sat, 26 Sep 2015 20:26:28 -0600 MIME-Version: 1.0 In-Reply-To: <560710F4.40003@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="oefS6G31rvoWF9MeXFb3l82KwVcKaQm8g" Subject: Re: [Qemu-devel] [PATCH v5 07/46] qapi: Don't pass pre-existing error to later call List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: Michael Roth , marcandre.lureau@redhat.com, qemu-devel@nongnu.org, ehabkost@redhat.com, DirtY.iCE.hu@gmail.com This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --oefS6G31rvoWF9MeXFb3l82KwVcKaQm8g Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 09/26/2015 03:41 PM, Eric Blake wrote: > On 09/24/2015 08:58 AM, Markus Armbruster wrote: >> Eric Blake writes: >> >>> Due to the existing semantics of the error_set() family, >>> generated sequences in the qapi visitors such as: >>> >>> visit_start_implicit_struct(m, (void **)obj, sizeof(FOO), &err); >>> if (!err) { >>> visit_type_FOO_fields(m, obj, errp); >>> visit_end_implicit_struct(m, &err); >>> } >>> error_propagate(errp, err); >> >> Indentation seems off. Intentional? >> >>> >>> are risky: if visit_type_FOO_fields() sets errp, and then >>> visit_end_implicit_struct() also encounters an error, the >>> attempt to overwrite the first error will cause an abort(). >=20 > I didn't even read error_propagate()'s contract correctly. It > specifically specifies that if errp is already set, then err is ignored= =2E >=20 > So the above sequence is actually just fine, because only the following= > paths exist: >=20 >=20 > As such, I'm revisiting if anything is needed at all, other than making= > the various visit_start/visit_end patterns consistent with one another > using existing idioms, and it may turn out we don't need the ternary > after all. Turns out patch 29/46 needs the ternary. There, I'm changing the logic of the various visit_type_FOO() to explicitly set *obj =3D NULL if something fails in between visit_start_* and visit_end_* - but to do that, I _have_ to track everything locally in &err (since errp might be NULL in the caller). That is, in the above example, if visit_type_FOO_fields() fails, we need to track that locally in order to clean up *obj. Meanwhile, the call to visit_end_implicit_struct() must be unconditional, whether or not we have detected earlier failure. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --oefS6G31rvoWF9MeXFb3l82KwVcKaQm8g Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJWB1PUAAoJEKeha0olJ0NqU1cH/R1mtRZsRc0QKPoLwFX+r3QA mo4S0x0SEVrAfd8BAX39HTa+TsAPOfXSD9xwYDaAaKh5KSAN38T1ULc+Hi/yjJId +AUBIj3Uwqa437CTS9vm0IM4e7Zq1kyXHPYIzZ21dkqUaJWH5OPKv1AIauZjUm0W gsxjjNhgP+8j5AYQRdWo/MRzTwNrbOdu/ta/H728q1/odmEZ3kDmM+m9D7dFmmOk JZsaYUqutZC8RTvYOlMUXAy1JxMIH9VQCGQwe5BggRU2sBHBHg/ZqIn4NQNFiime MNqkNsC4E5wJrOEGcR/t+dOdP7YiWy8JX+lT3MqCGZWb8ufvtIoEbU1wS6PmIRY= =5y2q -----END PGP SIGNATURE----- --oefS6G31rvoWF9MeXFb3l82KwVcKaQm8g--