From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:52750) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ScJ7f-0001Rd-Ja for qemu-devel@nongnu.org; Wed, 06 Jun 2012 12:30:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ScJ7Z-0002j0-9A for qemu-devel@nongnu.org; Wed, 06 Jun 2012 12:30:15 -0400 Received: from mail-pz0-f45.google.com ([209.85.210.45]:50012) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ScJ7Y-0002gU-VA for qemu-devel@nongnu.org; Wed, 06 Jun 2012 12:30:09 -0400 Received: by dadv2 with SMTP id v2so9783461dad.4 for ; Wed, 06 Jun 2012 09:30:06 -0700 (PDT) Sender: fluxion Date: Wed, 6 Jun 2012 11:30:00 -0500 From: Michael Roth Message-ID: <20120606163000.GD7733@illuin> References: <1338998427-13253-1-git-send-email-lersek@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1338998427-13253-1-git-send-email-lersek@redhat.com> Subject: Re: [Qemu-devel] [PATCH qom-next] qapi: exclude negative values in uint*_t Visitor interfaces List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Laszlo Ersek Cc: pbonzini@redhat.com, afaerber@suse.de, qemu-devel@nongnu.org On Wed, Jun 06, 2012 at 06:00:27PM +0200, Laszlo Ersek wrote: > > Signed-off-by: Laszlo Ersek > --- > (To be applied on top of 0f2de4a8.) > > qapi/qapi-visit-core.c | 11 ++++++++--- > 1 files changed, 8 insertions(+), 3 deletions(-) > > diff --git a/qapi/qapi-visit-core.c b/qapi/qapi-visit-core.c > index 9a29674..81f697f 100644 > --- a/qapi/qapi-visit-core.c > +++ b/qapi/qapi-visit-core.c > @@ -106,7 +106,7 @@ void visit_type_uint8(Visitor *v, uint8_t *obj, const char *name, Error **errp) > } else { > value = *obj; > v->type_int(v, &value, name, errp); > - if (value > UINT8_MAX) { > + if (value < 0 || value > UINT8_MAX) { > error_set(errp, QERR_INVALID_PARAMETER_VALUE, name ? name : "null", > "uint8_t"); > return; > @@ -125,7 +125,7 @@ void visit_type_uint16(Visitor *v, uint16_t *obj, const char *name, Error **errp > } else { > value = *obj; > v->type_int(v, &value, name, errp); > - if (value > UINT16_MAX) { > + if (value < 0 || value > UINT16_MAX) { > error_set(errp, QERR_INVALID_PARAMETER_VALUE, name ? name : "null", > "uint16_t"); > return; > @@ -144,7 +144,7 @@ void visit_type_uint32(Visitor *v, uint32_t *obj, const char *name, Error **errp > } else { > value = *obj; > v->type_int(v, &value, name, errp); > - if (value > UINT32_MAX) { > + if (value < 0 || value > UINT32_MAX) { > error_set(errp, QERR_INVALID_PARAMETER_VALUE, name ? name : "null", > "uint32_t"); > return; > @@ -163,6 +163,11 @@ void visit_type_uint64(Visitor *v, uint64_t *obj, const char *name, Error **errp > } else { > value = *obj; > v->type_int(v, &value, name, errp); > + if (value < 0) { > + error_set(errp, QERR_INVALID_PARAMETER_VALUE, name ? name : "null", > + "uint64_t"); > + return; > + } Sorry, responded a bit late in the last thread. But 2^64-1 is a valid value for visit_type_uint64(), yet due to being stored to a int64_t, it will fail the < 0 check, which introduces a regression for an acceptable use-case. The other checks make sense, however, since the max values do not exceed the max signed range of the intermediate int64_t we store to, so they're not ambiguous. > *obj = value; > } > } > -- > 1.7.1 > >