From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50491) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yzkjl-0000hy-NR for qemu-devel@nongnu.org; Tue, 02 Jun 2015 07:52:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yzkjg-0007IS-Oe for qemu-devel@nongnu.org; Tue, 02 Jun 2015 07:52:05 -0400 Received: from mx1.redhat.com ([209.132.183.28]:51486) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yzkjg-0007IG-IZ for qemu-devel@nongnu.org; Tue, 02 Jun 2015 07:52:00 -0400 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 9735CA0CAA for ; Tue, 2 Jun 2015 11:51:59 +0000 (UTC) From: Markus Armbruster References: <1432815695-31687-1-git-send-email-armbru@redhat.com> <20150529085154.GB3804@noname.redhat.com> <877frr4oig.fsf@blackfin.pond.sub.org> <556870FC.3020806@redhat.com> Date: Tue, 02 Jun 2015 13:51:56 +0200 In-Reply-To: <556870FC.3020806@redhat.com> (Eric Blake's message of "Fri, 29 May 2015 08:00:28 -0600") Message-ID: <87wpzmba5f.fsf@blackfin.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Qemu-devel] [PATCH 0/9] Miscellaneous error reporting improvements List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: Kevin Wolf , pbonzini@redhat.com, qemu-devel@nongnu.org Eric Blake writes: > On 05/29/2015 05:22 AM, Markus Armbruster wrote: >> Kevin Wolf writes: >> >>> Am 28.05.2015 um 14:21 hat Markus Armbruster geschrieben: >>>> Touches vl.c, which gives me pretext to ask Paolo: would you be >>>> willing to take this through your tree? Or should I take it through >>>> mine? >>> >>> After this series we have an ugly half-converted state where >>> qemu_opts_foreach() has both a return code and an Error object, >>> and it's not generally true that an error is set for a failing >>> return code. >>> >>> The most confusing part about this is that you have &error_abort almost >>> everywhere, but the function doesn't actually abort on error, but rather >>> returns a negative error code and leaves errp alone. >> >> True. The function contract spells it out, which hopefully reduces the >> confusion somewhat. > > Except that you don't enforce the contract; I suggested adding > assert(!*errp) at the right place in the two conversions. > >> >> Would you find NULL less confusing than &error_abort? > > NULL says to ignore errors, &error_abort says to diagnose errors as > programming bugs. If we know we aren't going to have an error, I prefer > diagnosing coding bugs. You prefer &error_abort, Kevin prefers NULL, so I need to figure out what I prefer to break the tie :) I think we can agree on these two rules on Error ** arguments: R1: When caller doesn't care whether the callee sets an error, it should pass NULL. R2: When a caller relies on the callee not setting an error, it should pass &error_abort. R1 applies, R2 does not, thus we should pass NULL. The case for &error_abort requires a third rule: Proposed R3: When a caller knows that the callee won't set an error, it may pass &error_abort to document this knowledge even when it doesn't actually rely on it (thus R2 doesn't apply). This is an exception to R1. To keep things simple, I lean towards rejecting R3 and passing NULL. Opinions?