From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:35272) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ScIDQ-0002Gd-Nq for qemu-devel@nongnu.org; Wed, 06 Jun 2012 11:32:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ScIDN-0006Qr-JV for qemu-devel@nongnu.org; Wed, 06 Jun 2012 11:32:08 -0400 Received: from mail-pb0-f45.google.com ([209.85.160.45]:54507) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ScIDN-0006Qb-Ab for qemu-devel@nongnu.org; Wed, 06 Jun 2012 11:32:05 -0400 Received: by pbbro12 with SMTP id ro12so9912087pbb.4 for ; Wed, 06 Jun 2012 08:32:03 -0700 (PDT) Sender: fluxion Date: Wed, 6 Jun 2012 10:31:57 -0500 From: Michael Roth Message-ID: <20120606153157.GP2916@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> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20120606151640.GA7733@illuin> 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: Paolo Bonzini Cc: Laszlo Ersek , Andreas =?iso-8859-1?Q?F=E4rber?= , qemu-devel@nongnu.org On Wed, Jun 06, 2012 at 10:16:40AM -0500, Michael Roth wrote: > On Wed, Jun 06, 2012 at 04:10:44PM +0200, Paolo Bonzini wrote: > > Il 06/06/2012 15:31, Andreas Färber ha scritto: > > >> > > > >> > (a) add < 0 checks to and > > >> > include it in the series, > > >> > (b) make all Netdev integer types as strict as possible, remove > > >> > superfluous checks, > > >> > (c) render NetLegacy::name optional. > > >> > > > >> > How do I lay out (a)? Should I include the patch verbatim first (with > > >> > proper From: and Signed-off-by: lines) and then modify it in a small > > >> > followup, or squash those two and... what? :) > > > I am missing context here. The referenced patch is on qom-next already > > > and will thus be in my upcoming PULL (today or tomorrow) unless someone > > > comments on that patch, cc'ing me, that there's an error. Feel free to > > > cherry-pick from there but do not squash into random series please. > > > > > > I don't understand what < 0 checks you are talking about, lacking time > > > to go through this QIDL patch series ATM. > > > > The uintXX visitors do not fail if you pass a negative value. I'm fine > > with including the patch with the small bug and fixing it as a > > follow-up, there's plenty of time before 1.2. > > How would we implement such a check? > > In the case of uint64_t, the field we're visiting is passed in as a > uint64_t*, so -1 is indistinguishable from the unsigned interpretation > of the field, which is within the valid range. > > For uintXX_t where XX < 64, a negative value would exceed the UINTXX_MAX > check, so those cases are already handled. Argh, scratch that, same faulty logic that caused me to miss this the first time around. We're storing to an intermediate int64_t rather than a uint64_t, so a negative value would still pass the check, so a < 0 check is warranted. Agreed this should be a seperate patch though. > > Or am I missing something? > > > > > Paolo > >