From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:50689) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ScNK1-0007FC-2d for qemu-devel@nongnu.org; Wed, 06 Jun 2012 16:59:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ScNJz-0002aY-81 for qemu-devel@nongnu.org; Wed, 06 Jun 2012 16:59:16 -0400 Received: from cantor2.suse.de ([195.135.220.15]:46584 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ScNJy-0002aQ-UZ for qemu-devel@nongnu.org; Wed, 06 Jun 2012 16:59:15 -0400 Message-ID: <4FCFC49A.7040202@suse.de> Date: Wed, 06 Jun 2012 22:59:06 +0200 From: =?ISO-8859-1?Q?Andreas_F=E4rber?= 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: quoted-printable 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: Blue Swirl , Paolo Bonzini , Laszlo Ersek , qemu-devel@nongnu.org Am 06.06.2012 22:09, schrieb Michael Roth: > On Wed, Jun 06, 2012 at 06:49:19PM +0200, Laszlo Ersek wrote: >> On 06/06/12 18:14, Michael Roth wrote: >>> On Wed, Jun 06, 2012 at 05:30:03PM +0200, Laszlo Ersek wrote: >> >>>> value < 0 >>> >>> I think this last one will cause problems though, since uint64_t's >>> within the valid range for visit_type_uint64() will fail due to being >>> interpreted as < 0 when cast to int64_t. With the others we can detec= t >>> these cases since the max unsigned value doesn't exceed the max signe= d >>> value of the intermediate type we're storing to. >> >> 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 >=20 > 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 comm= on > throughout the tree. >=20 >> an error in this case. If a visitor genuinely wants to parse and store >> 2^63 for example, it should implement the "type_uint64" interface. >=20 > This doesn't buy us much, since ultimately that type_uint64 interface i= s > just gonna, in the case of QMP*Visitor anyway, end up casting back/fort= h > between a int64_t anyway so we can stick it into a QObject as a Qint. >=20 > So really we end up doing the same thing as before, except we do it in > more places. >=20 >> >> Anyway I've been called "inflexible" before. I can send a v2 if you wi= sh. >=20 > Your offer to send a v2 suggests otherwise :) [snip] I've squashed the first three hunks on my qom-next-1 branch and am listening what comes out of the discussion for the fourth one. Do we have an actual example where this discussion makes a difference? The RAM "size" property for sun4m and sun4u seem to be the only uses of DEFINE_PROP_UINT64(). For anything else I haven't seen patches yet, so I think we could defer that to a follow-up patch? I'd like to have qom-next pulled sooner rather than later. ;-) Andreas --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=F6rffer; HRB 16746 AG N=FCrnbe= rg