From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:41415) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UDGOF-00060F-4z for qemu-devel@nongnu.org; Wed, 06 Mar 2013 10:36:25 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UDGOC-0003sD-7Y for qemu-devel@nongnu.org; Wed, 06 Mar 2013 10:36:23 -0500 Received: from mx1.redhat.com ([209.132.183.28]:60887) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UDGOB-0003s8-Ug for qemu-devel@nongnu.org; Wed, 06 Mar 2013 10:36:20 -0500 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r26FaIcc029473 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 6 Mar 2013 10:36:19 -0500 Message-ID: <513762EF.3030809@redhat.com> Date: Wed, 06 Mar 2013 16:38:23 +0100 From: Laszlo Ersek MIME-Version: 1.0 References: <1362566886-14073-1-git-send-email-kwolf@redhat.com> <513722BD.6010503@redhat.com> <20130306111126.GA2285@dhcp-200-207.str.redhat.com> <513756D5.1020506@redhat.com> <51375B04.9020402@redhat.com> <20130306151905.GB2285@dhcp-200-207.str.redhat.com> In-Reply-To: <20130306151905.GB2285@dhcp-200-207.str.redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] qemu-sockets: Fix assertion failure List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: Paolo Bonzini , qemu-devel@nongnu.org, Luiz Capitulino On 03/06/13 16:19, Kevin Wolf wrote: > Am 06.03.2013 um 16:04 hat Paolo Bonzini geschrieben: >> Il 06/03/2013 15:46, Laszlo Ersek ha scritto: >>>>> We could assert(!error_is_set(errp)) if we wanted. As soon as you've got >>>>> an Error, you must return instead of calling more functions with the >>>>> same error pointer. >>> I think Luiz would suggest (*) to receive any error into a >>> NULL-initialized local_err pointer; do the logic above on local_err, and >>> just before returning, error_propagate() it to errp. >>> >>> (*) I hope you can see what I did there: if you disagree, you get to >>> take that to Luiz, even though he didn't say anything. I'm getting >>> better at working this list! :) >> >> I agree with Laszlo. > > I don't really understand the difference. As long as the function > doesn't depend on the Error object to be present (which it doesn't), > isn't it semantically exactly the same? The difference is when the caller passes in an already set Error. In this case you release that and replace it with your own error. Usually we stick to the first error encountered. Under the above suggestion you'd keep error handling internal to yourself, and in the end make one attempt to propagate it outwards. If the caller has passed in NULL, the error is dropped. If the caller's passed in a preexistent error, then that one takes precedence and the new one is dropped (but it doesn't interfere with the internal logic). Third, the caller can even accept your error. error_propagate() and error_set() deal with the overwrite attempt differently. The former silently drops the newcomer, whereas the latter assert()s. Of course one wonders why a caller would pass in a preexistent Error. Laszlo