From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48723) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VoWJO-0006NL-MD for qemu-devel@nongnu.org; Thu, 05 Dec 2013 05:37:44 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VoWJJ-0003yn-Kx for qemu-devel@nongnu.org; Thu, 05 Dec 2013 05:37:38 -0500 Received: from mx1.redhat.com ([209.132.183.28]:42651) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VoWJJ-0003ye-Cn for qemu-devel@nongnu.org; Thu, 05 Dec 2013 05:37:33 -0500 Message-ID: <52A05767.60703@redhat.com> Date: Thu, 05 Dec 2013 11:37:27 +0100 From: Paolo Bonzini 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: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 Cc: Peter Crosthwaite , Markus Armbruster , afaerber@suse.de, qemu-devel@nongnu.org Il 03/12/2013 21:33, Igor Mammedov ha scritto: > 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 impossible. > Why is ignoring errors from "void foo(...)" like API considered acceptable? See http://permalink.gmane.org/gmane.comp.emulators.qemu/243779 > * Peter's alternative > + self-documenting > + consistent > + predictable I'll add another small advantage which is fewer SLOC. > * make Error* mandatory for all void functions > + consistent > + almost predictable (because in C you can ignore return values) > - not necessarily does the right thing (e.g. cleanup functions) > - requires manual effort to abide to the policy Better wording of the last: a missing &error_abort is easier to spot than a missing assert_no_error(errp). Paolo