From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:48759) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QOXFz-0000lY-G6 for qemu-devel@nongnu.org; Mon, 23 May 2011 11:41:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QOXFy-0004zt-3o for qemu-devel@nongnu.org; Mon, 23 May 2011 11:41:23 -0400 Received: from mx1.redhat.com ([209.132.183.28]:64598) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QOXFx-0004zo-S1 for qemu-devel@nongnu.org; Mon, 23 May 2011 11:41:22 -0400 Date: Mon, 23 May 2011 16:41:16 +0100 From: "Daniel P. Berrange" Message-ID: <20110523154116.GZ24143@redhat.com> References: <20110520180331.GA21837@amd.home.annexia.org> <4DD6AEB9.6060506@codemonkey.ws> <20110523130411.GR24143@redhat.com> <4DDA620F.1090308@codemonkey.ws> <20110523134021.GT24143@redhat.com> <4DDA6512.2040405@codemonkey.ws> <20110523141408.GV24143@redhat.com> <4DDA7736.9010904@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <4DDA7736.9010904@codemonkey.ws> Subject: Re: [Qemu-devel] [PATCH] qemu: json: Fix parsing of integers >= 0x8000000000000000 Reply-To: "Daniel P. Berrange" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: "Richard W.M. Jones" , qemu-devel@nongnu.org, Luiz Capitulino On Mon, May 23, 2011 at 10:03:18AM -0500, Anthony Liguori wrote: > On 05/23/2011 09:14 AM, Daniel P. Berrange wrote: > >On Mon, May 23, 2011 at 08:45:54AM -0500, Anthony Liguori wrote: > >>On 05/23/2011 08:40 AM, Daniel P. Berrange wrote: > >>>On Mon, May 23, 2011 at 08:33:03AM -0500, Anthony Liguori wrote: > >>>>On 05/23/2011 08:04 AM, Daniel P. Berrange wrote: > >>>>>On Fri, May 20, 2011 at 01:11:05PM -0500, Anthony Liguori wrote: > >>>>>>On 05/20/2011 01:03 PM, Richard W.M. Jones wrote: > >>>>>>> > >>>>>>>There seem to be a few unsafe uses of strto* functions. This patch > >>>>>>>just fixes the one that affects me :-) > >>>>>> > >>>>>>Sending an integer of this size is not valid JSON. > >>>>>> > >>>>>>Your patch won't accept negative numbers, correct? > >>>>>> > >>>>>>JSON only supports int64_t. > >>>>> > >>>>>That's not really true. JSON supports arbitrarily large numbers > >>>>>& integers. > >>>> > >>>>Try the following snippet in your browser: > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>The actual value of the alert will surprise you :-) > >>>> > >>>>Integers in Javascript are actually represented as doubles > >>>>internally which means that integer constants are only accurate up > >>>>to 52 bits. > >>>> > >>>>So really, we should cap integers at 32-bit :-/ > >>>> > >>>>Have I mentioned recently that I really dislike JSON... > >>> > >>>NB, I am distinguishing between JSON the generic specification and > >>>JSON as implemented in web browsers. JSON the specification has *no* > >>>limitation on integers. Any limitation, like the one you demonstrate, > >>>is inherantly just specific to the implementation. > >> > >>No, EMCA is very specific in how integers are handled in JavaScript. > >>Every implementation of JavaScript is going to exhibit this > >>behavior. > >> > >>The JSON specification lack of specificity here I think has to be > >>interpreted as a deferral to the EMCA specification. > > > >The EMCA spec declares that integers upto 52-bits can be stored > >without loosing precision. This doesn't forbid sending of 64-bit > >integers via JSON. It merely implies that when parsed into a > >EMCA-Script object you'll loose precision. So this doesn't mean that > >QEMU has to throw away the extra precision when parsing JSON, nor > >do client apps have to throw away precision when generating JSON > >for QEMU. Both client& QEMU can use a full uint64 if desired. > > Thinking more carefully about this, I think the following rule is important: > > 1) Integers that would cause overflow should be treated as double > precision floating point numbers. > > 2) A conforming implementation must support integer precision up to > 52-bit signed integers. > > I think this is valid because the string: > > 9223372036854775808 > > Is a representation of: > > 9223372036854776e3 > > Both are equivalent representations of the same number. So we can > send and accept arbitrarily large integers provided that we always > fallback to representing integers as double precision floating > points if the integer would otherwise truncate. > > I think this means we need to drop QFloat and QInt, add a QNumber, > and then add _from_uint64/to_uint64 and _from_double/to_double. As long as QNumber is using the string as its internal representation, and only converting to a more limited integer/float format at time of use, this sounds workable. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|