From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:51738) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QOVth-0000va-59 for qemu-devel@nongnu.org; Mon, 23 May 2011 10:14:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QOVtf-00042p-Ln for qemu-devel@nongnu.org; Mon, 23 May 2011 10:14:17 -0400 Received: from mx1.redhat.com ([209.132.183.28]:39825) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QOVtf-00042j-Bx for qemu-devel@nongnu.org; Mon, 23 May 2011 10:14:15 -0400 Date: Mon, 23 May 2011 15:14:08 +0100 From: "Daniel P. Berrange" Message-ID: <20110523141408.GV24143@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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <4DDA6512.2040405@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: Luiz Capitulino , qemu-devel@nongnu.org, "Richard W.M. Jones" 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. > But to the point, I don't see what the point of using JSON is if our > interpretation doesn't actually work with JavaScript. This simply means JavaScript is a useless language for talking to the QEMU monitor, because it'll loose precision for integers > 52bits. > >We have no need to > >limit ourselves to what web browsers currently support for integers in > >JSON. > > It's not web browsers. This behavior is well specified in the EMCA > specification. > > >Indeed, limiting ourselves to what browsers support will make the > >JSON monitor mode essentially useless, requiring yet another new mode > >with a format which can actually represent the data we need to use. > > > >What I suggested is in compliance with the JSON specification and allows > >us to support uint64 which we need for commands which take disk or memory > >offsets. > > At the end of the day, we need to worry about supporting clients. I > think clients are going to refer to the behavior of JavaScript for > guidance. So if we expect a client to not round integers, we can't > send ones that are greater than 52-bit. > > This is an extremely nasty silent failure mode. > > Or, we need to just say that we're not JSON compatible. I don't see this as a JSON compatiblity problem. JSON allows arbitrary numbers, the only restriction is wrt to the precision of the parsers when using JavaScript. A C app can encode+decode a value of MAX_UINT64 in JSON precisely and remain JSON compatible. A JavaScript app will still be able to decode the values without any trouble, it will simply loose some precision at time of parsing. 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 :|