From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40616) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YyJce-0005cm-No for qemu-devel@nongnu.org; Fri, 29 May 2015 08:42:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YyJcd-0002n7-Hl for qemu-devel@nongnu.org; Fri, 29 May 2015 08:42:48 -0400 Received: from mx1.redhat.com ([209.132.183.28]:54315) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YyJcd-0002my-CQ for qemu-devel@nongnu.org; Fri, 29 May 2015 08:42:47 -0400 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (Postfix) with ESMTPS id 071862C770E for ; Fri, 29 May 2015 12:42:47 +0000 (UTC) Date: Fri, 29 May 2015 14:42:45 +0200 From: Kevin Wolf Message-ID: <20150529124245.GG3804@noname.redhat.com> References: <1432815695-31687-1-git-send-email-armbru@redhat.com> <20150529085154.GB3804@noname.redhat.com> <877frr4oig.fsf@blackfin.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <877frr4oig.fsf@blackfin.pond.sub.org> Subject: Re: [Qemu-devel] [PATCH 0/9] Miscellaneous error reporting improvements List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: pbonzini@redhat.com, qemu-devel@nongnu.org Am 29.05.2015 um 13:22 hat Markus Armbruster geschrieben: > 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. > > Would you find NULL less confusing than &error_abort? That might be better, yes. At least it doesn't imply that no errors can happen, just that we don't handle them. In places that actually do handle errors using the return code even though passing a NULL errp, that is obvious and doesn't lead to assumptions about the called function. > > If you don't want to complete the conversion, can we add it to that wiki > > page with the list half-done conversions at least? > > Can do. > > "That wiki page" = http://wiki.qemu.org/CodeTransitions Yes, that's the one I meant. Thanks. Kevin