From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46100) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VXcjp-00023m-EB for qemu-devel@nongnu.org; Sat, 19 Oct 2013 16:03:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VXcjj-0006oA-El for qemu-devel@nongnu.org; Sat, 19 Oct 2013 16:03:05 -0400 Received: from mx1.redhat.com ([209.132.183.28]:12229) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VXcjj-0006nt-7Q for qemu-devel@nongnu.org; Sat, 19 Oct 2013 16:02:59 -0400 Message-ID: <5262E56D.2090808@redhat.com> Date: Sat, 19 Oct 2013 22:02:53 +0200 From: Max Reitz MIME-Version: 1.0 References: <1381803804-4551-1-git-send-email-famz@redhat.com> <525EE171.20208@redhat.com> <20131017124928.GI10774@stefanha-thinkpad.redhat.com> <20131017130023.GD2942@dhcp-200-207.str.redhat.com> <20131018085150.GA27034@T430s.nay.redhat.com> <52617702.1080906@redhat.com> <20131019080525.GA2727@dhcp-200-207.str.redhat.com> In-Reply-To: <20131019080525.GA2727@dhcp-200-207.str.redhat.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH v2] mirror: drop local_err in mirror_complete List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: Stefan Hajnoczi , famz@redhat.com, qemu-devel@nongnu.org, stefanha@redhat.com On 2013-10-19 10:05, Kevin Wolf wrote: > Am 18.10.2013 um 19:59 hat Max Reitz geschrieben: >> Then there's still the problem that I'm not the one who introduced >> error_propagate. Someone obviously intended some purpose for it, so >> even if it doesn't make a difference now (and my RFC is unneeded), >> I'd still use it to propagate errors (instead of passing the error >> pointer). My point being that there *is* a function for propagating >> errors and I think we should therefore use it. The current qemu code >> seems to alternate between the two alternatives, although using >> error_propagate seems more common to me (at least, that was the >> result when I looked through the code trying to decide whether to >> use it or not). >> >> Generally, we need a proper discussion about whether error_propagate >> is obsolete or not. Afterwards, we can adapt the current codebase to >> the result of that discussion; but until then, I oppose changing >> existing code without actual need to do so but personal preference. >> >> Max >> >> >> PS: I wrote my error_propagate RFC in part because I was >> disappointed about how much of a no-op error_propagate actually is >> and was trying to change that. ;-) > It's not a no-op. That's why I wrote =93how much of a=94 instead of =93that error_propagate= is a=20 no-op=94. ;-) > The point is that the caller can pass NULL as errp if > it isn't interested in the error message. If you do anything else with > errp than just passing it to other functions - most commonly a > error_is_set() check - you need to make sure that you use a local Error > variable and propagate it. Otherwise, if the caller passed NULL, your > error path would never get executed. Okay, together with Paolo's comment I believe I now can see the meaning=20 of error_propagate and its intended use; thank you both for explaining. Max