From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:56500) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ScMXd-0001RP-Gi for qemu-devel@nongnu.org; Wed, 06 Jun 2012 16:09:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ScMXb-0000aO-Kl for qemu-devel@nongnu.org; Wed, 06 Jun 2012 16:09:17 -0400 Received: from mail-pb0-f43.google.com ([209.85.160.43]:58345) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ScMXb-0000aE-Bu for qemu-devel@nongnu.org; Wed, 06 Jun 2012 16:09:15 -0400 Received: by pbcwz7 with SMTP id wz7so4212pbc.2 for ; Wed, 06 Jun 2012 13:09:13 -0700 (PDT) Sender: fluxion Date: Wed, 6 Jun 2012 15:09:07 -0500 From: Michael Roth Message-ID: <20120606200907.GQ2916@illuin> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4FCF8A0F.3020306@redhat.com> 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: Laszlo Ersek Cc: Paolo Bonzini , Andreas =?iso-8859-1?Q?F=E4rber?= , qemu-devel@nongnu.org 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 detect > > these cases since the max unsigned value doesn't exceed the max signed > > 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 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. > 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. This doesn't buy us much, since ultimately that type_uint64 interface is just gonna, in the case of QMP*Visitor anyway, end up casting back/forth between a int64_t anyway so we can stick it into a QObject as a Qint. So really we end up doing the same thing as before, except we do it in more places. > > Anyway I've been called "inflexible" before. I can send a v2 if you wish. Your offer to send a v2 suggests otherwise :) > > Thanks, > Laszlo >