From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:37778) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sqs9P-0000EA-En for qemu-devel@nongnu.org; Mon, 16 Jul 2012 16:44:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Sqs9O-00022B-Gh for qemu-devel@nongnu.org; Mon, 16 Jul 2012 16:44:15 -0400 Received: from mx1.redhat.com ([209.132.183.28]:54275) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sqs9O-000221-91 for qemu-devel@nongnu.org; Mon, 16 Jul 2012 16:44:14 -0400 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q6GKiCOk028357 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 16 Jul 2012 16:44:13 -0400 Date: Mon, 16 Jul 2012 17:44:48 -0300 From: Luiz Capitulino Message-ID: <20120716174448.605127cd@doriath.home> In-Reply-To: <50047A1E.8030304@redhat.com> References: <1339575768-2557-1-git-send-email-lersek@redhat.com> <1339575768-2557-2-git-send-email-lersek@redhat.com> <20120713133852.3a446672@doriath.home> <50005B3D.2070009@redhat.com> <500072D3.2060901@redhat.com> <20120716141200.5bbed537@doriath.home> <50047A1E.8030304@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2 01/17] qapi: fix error propagation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Laszlo Ersek Cc: Paolo Bonzini , qemu-devel@nongnu.org On Mon, 16 Jul 2012 22:31:26 +0200 Laszlo Ersek wrote: > On 07/16/12 19:12, Luiz Capitulino wrote: > > On Fri, 13 Jul 2012 21:11:15 +0200 > > Paolo Bonzini wrote: > > > > >> I think doing it for error_set was just for symmetry and to avoid > >> introducing excessive complexity. > > > > We already check if the error is set in several places, and I don't think > > it will add much complexity. I still think that an assert() is better. > > If that means that the generated traversal code takes responsibility to > call any visitor callback with a fresh error receptacle, IOW I can go > ahead and just use error_set() in OptsVisitor and any firing assert will > be blamed on the generator: fine :) If that means it's finding bugs then that's great. On the other hand, if it shows only false positives and we end up having to re-work the code just to avoid that, then I'd agree on not having an assert().