From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:48270) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Scatc-00044A-63 for qemu-devel@nongnu.org; Thu, 07 Jun 2012 07:29:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ScatX-0003x8-8i for qemu-devel@nongnu.org; Thu, 07 Jun 2012 07:28:55 -0400 Received: from mx1.redhat.com ([209.132.183.28]:21017) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ScatX-0003wy-0M for qemu-devel@nongnu.org; Thu, 07 Jun 2012 07:28:51 -0400 Message-ID: <4FD090B2.4090305@redhat.com> Date: Thu, 07 Jun 2012 13:29:54 +0200 From: Laszlo Ersek MIME-Version: 1.0 References: <1337683555-13301-1-git-send-email-lersek@redhat.com> <4FCE7684.2070206@redhat.com> <4FCF5512.9000704@redhat.com> <4FCF5BA8.3010201@suse.de> <4FCF64E4.50701@redhat.com> <20120606151640.GA7733@illuin> <4FCF777B.7000806@redhat.com> <20120606161446.GC7733@illuin> <4FCF8A0F.3020306@redhat.com> <20120606200907.GQ2916@illuin> In-Reply-To: <20120606200907.GQ2916@illuin> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 00/16] introduce OptsVisitor, rebase -net/-netdev parsing List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Michael Roth Cc: Paolo Bonzini , =?ISO-8859-1?Q?Andreas_F=E4rbe?= =?ISO-8859-1?Q?r?= , qemu-devel@nongnu.org On 06/06/12 22:09, Michael Roth wrote: > On Wed, Jun 06, 2012 at 06:49:19PM +0200, Laszlo Ersek wrote: >> The fallback (*v->type_int)() call stores an int64_t, according to its >> prototype ("interface contract"). IMHO it shouldn't try to communicate a >> mathematical value outside of [INT64_MIN, INT64_MAX]; it should report > > But the contract with visit_type_int() is maintained: it's just that > visit_type_uint64() is casting it's uint64_t value to int64_t (and > back) to make use of the fallback. It's slightly dirty, but fairly common > throughout the tree. (I'm going theoretical :)) Sorry, I didn't mean what happens "around" the type_int method; I meant what happens inside it. A visitor type takes some "external type" (a bag of data, structured or unstructured) and provides functions with scalar target types (among other things). One defines a native C struct in the JSON (... I'm making some leaps here), the generated code traverses that C type, and probes the "bag of data" with the corresponding visitor. A type_int call made to the visitor says "hey I need an int64_t for this node of the target C struct, with this 'path' and 'name' locator inside the external object". If the 'path' (= eg. visitor stack) and 'name' identify a piece of info in the external object that can't be represented in the requested target type, the visitor should report an error. I don't see much difference between the decimal representation of 2^63 and the string "donkey" in this regard if the target C "node" is an int64_t. (Musing block ends :)) Of course I'm fine with dropping the fourth hunk. Thanks, Laszlo