From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:33094) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UaltP-0007VY-L5 for qemu-devel@nongnu.org; Fri, 10 May 2013 07:53:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UaltM-0007kB-1y for qemu-devel@nongnu.org; Fri, 10 May 2013 07:53:43 -0400 Received: from mx1.redhat.com ([209.132.183.28]:33395) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UaltL-0007gq-RN for qemu-devel@nongnu.org; Fri, 10 May 2013 07:53:40 -0400 Message-ID: <518CE04B.605@redhat.com> Date: Fri, 10 May 2013 13:55:55 +0200 From: Laszlo Ersek MIME-Version: 1.0 References: <1368152462-13219-1-git-send-email-mdroth@linux.vnet.ibm.com> <1368152462-13219-7-git-send-email-mdroth@linux.vnet.ibm.com> In-Reply-To: <1368152462-13219-7-git-send-email-mdroth@linux.vnet.ibm.com> Content-Type: text/plain; charset=ISO-8859-1 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, qemu-devel@nongnu.org, lcapitulino@redhat.com On 05/10/13 04:20, 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) > > 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))); > I wanted to correct you here and propose s/mantissa/fractional part/ everywhere in this patch (including commit message and patch body). However tells me one meaning of "mantissa" *is* "fractional part". In that sense I won't try to "correct" you, but can you consider doing the replacement still, in order not to confuse non-native speakers who associate "mantissa" only with the third meaning Wiktionary gives, ie. the significand in FP representation? Otherwise the v2 series looks good to me (not R-b-ing it since you'll post v3 to address Amos's note). Thanks, Laszlo