From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:39415) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uap5D-0004Of-Pr for qemu-devel@nongnu.org; Fri, 10 May 2013 11:18:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Uap5B-0005A6-J4 for qemu-devel@nongnu.org; Fri, 10 May 2013 11:18:07 -0400 Received: from mx1.redhat.com ([209.132.183.28]:38294) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uap5B-00059t-AD for qemu-devel@nongnu.org; Fri, 10 May 2013 11:18:05 -0400 Date: Fri, 10 May 2013 11:17:17 -0400 From: Luiz Capitulino Message-ID: <20130510111717.4a9449a9@redhat.com> In-Reply-To: <1368152462-13219-7-git-send-email-mdroth@linux.vnet.ibm.com> References: <1368152462-13219-1-git-send-email-mdroth@linux.vnet.ibm.com> <1368152462-13219-7-git-send-email-mdroth@linux.vnet.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 06/10] json-parser: fix handling of large whole number values List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Michael Roth Cc: akong@redhat.com, lersek@redhat.com, qemu-devel@nongnu.org On Thu, 9 May 2013 21:20:58 -0500 Michael Roth wrote: > Currently our JSON parser assumes that numbers lacking a mantissa are > integers and attempts to store them as QInt/int64 values. This breaks in > the case where the number overflows/underflows int64 values (which is > still valid JSON) Anthony wanted to fix this by moving to another wire format :) But, how this patch related to this series? > > Fix this by detecting such cases and using a QFloat to store the value > instead. > > Signed-off-by: Michael Roth > --- > qobject/json-parser.c | 26 +++++++++++++++++++++++--- > 1 file changed, 23 insertions(+), 3 deletions(-) > > diff --git a/qobject/json-parser.c b/qobject/json-parser.c > index 05279c1..4d14e71 100644 > --- a/qobject/json-parser.c > +++ b/qobject/json-parser.c > @@ -640,9 +640,29 @@ static QObject *parse_literal(JSONParserContext *ctxt) > case JSON_STRING: > obj = QOBJECT(qstring_from_escaped_str(ctxt, token)); > break; > - case JSON_INTEGER: > - obj = QOBJECT(qint_from_int(strtoll(token_get_value(token), NULL, 10))); > - break; > + case JSON_INTEGER: { > + /* A possibility exists that this is a whole-valued float where the > + * mantissa was left out due to being 0 (.0). It's not a big deal to > + * treat these as ints in the parser, so long as users of the > + * resulting QObject know to expect a QInt in place of a QFloat in > + * cases like these. > + * > + * However, in some cases these values will overflow/underflow a > + * QInt/int64 container, thus we should assume these are to be handled > + * as QFloats/doubles rather than silently changing their values. > + * > + * strtoll() indicates these instances by setting errno to ERANGE > + */ > + int64_t value; > + > + errno = 0; /* strtoll doesn't set errno on success */ > + value = strtoll(token_get_value(token), NULL, 10); > + if (errno != ERANGE) { > + obj = QOBJECT(qint_from_int(value)); > + break; > + } > + /* fall through to JSON_FLOAT */ > + } > case JSON_FLOAT: > /* FIXME dependent on locale */ > obj = QOBJECT(qfloat_from_double(strtod(token_get_value(token), NULL)));