From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52483) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VnwoI-00073e-6N for qemu-devel@nongnu.org; Tue, 03 Dec 2013 15:43:15 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VnwoD-0002Rt-2f for qemu-devel@nongnu.org; Tue, 03 Dec 2013 15:43:10 -0500 Received: from mx1.redhat.com ([209.132.183.28]:58562) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VnwoC-0002RC-RB for qemu-devel@nongnu.org; Tue, 03 Dec 2013 15:43:05 -0500 Message-ID: <529E4256.40807@redhat.com> Date: Tue, 03 Dec 2013 13:43:02 -0700 From: Eric Blake MIME-Version: 1.0 References: <87a9ginu92.fsf@blackfin.pond.sub.org> <529DD58C.8020408@redhat.com> <87y5423ut9.fsf@blackfin.pond.sub.org> <20131203213348.3f4e345e@thinkpad> In-Reply-To: <20131203213348.3f4e345e@thinkpad> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="H2MijabA29jUl9tpi8JBVOC7x5GotRQll" Subject: Re: [Qemu-devel] [RFC PATCH v1 0/5] Add error_abort and associated cleanups List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Igor Mammedov , Markus Armbruster Cc: pbonzini@redhat.com, Peter Crosthwaite , qemu-devel@nongnu.org, afaerber@suse.de This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --H2MijabA29jUl9tpi8JBVOC7x5GotRQll Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 12/03/2013 01:33 PM, Igor Mammedov wrote: >>> Also, is it worth adding asserts and/or compiler annotations to requi= re >>> that the Error **err argument of functions be non-NULL, to ensure tha= t >>> callers are always passing either a valid destination or one of the >>> special addresses? But doing so would probably require adding a spec= ial >>> address for error_ignore for callers that intend to discard an error = in >>> cases where the return type of the function lets them know to proceed= >>> with a fallback implementation (that is, cases where ignoring an erro= r >>> makes sense). >> >> Right now, we use NULL as "ignore errors" argument. >> >> NULL gives us a chance to express "caller must not ignore errors" via >> some non-null annotation that gets fed to a static analyzer. >> >> I doubt that would be possible with a special error_ignore object. >> >> Anyway, this series is about "abort on error". Let's keep "ignore >> errors" issues separate. > I'm sorry for hijacking thread, but that actually an issue that started= an > original discussion. > Where void returning QOM API functions are used with NULL, without any = chance > to detect that error happened. So abusing NULL errp in this functions > might lead to hard to find runtime errors. > I think Eric's suggestion was to enforce passing non NULL errp and let = caller > to deal with error gracefully so that above mentioned misuse was imposs= ible. > Why is ignoring errors from "void foo(...)" like API considered accepta= ble? Okay, so it sounds like consensus is that using NULL as the means to ignore errors is okay when there is an alternative way to detect error, but that for any function that returns void, adding an assert(errp) would be appropriate because the caller cannot safely ignore the failure. It's not worth inventing an error_ignore special address, but for functions that have no way to report errors except via errp, then it IS worth enforcing that the caller is either prepared to handle the error or has passed &error_abort (or any other special addresses we add later). --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --H2MijabA29jUl9tpi8JBVOC7x5GotRQll Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJSnkJWAAoJEKeha0olJ0Nqmp8IAJG/Dk8y/fgpLnKty7g6sCZI WJgSEooB6/NThLRSK9XlDdDKgZ+ZTD0TKQ0KzSXdg3YHnQwmAd8/KufOE0CB+XXm oUQRuiytWUa/gGalKKQl6wCs2TJntRrM7K7GptVKo6++6u1/gcmJcepVi1esb9zR tQOI2aqnChcvUT6I9kYP/WxE4NRG/u1kP20c4JGCTNzeCnniBRyUHVoR+3dM4H2b TogMmDoGsci7BqlfDLWA6iZOe4CPVDz76v5kvK1efkB97m58dGRZOXZEJZc0yXvL lZmBqvC3BYbmCbb11by7JEUJ+AnBuvPfxMwOtwdKx9x7IwP0lWFIbsLo0glaOYQ= =037T -----END PGP SIGNATURE----- --H2MijabA29jUl9tpi8JBVOC7x5GotRQll--