From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:43444) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QOXeJ-0000Cs-CU for qemu-devel@nongnu.org; Mon, 23 May 2011 12:06:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QOXeI-0000hB-51 for qemu-devel@nongnu.org; Mon, 23 May 2011 12:06:31 -0400 Received: from mx1.redhat.com ([209.132.183.28]:7255) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QOXeH-0000h5-Sf for qemu-devel@nongnu.org; Mon, 23 May 2011 12:06:30 -0400 Date: Mon, 23 May 2011 17:06:23 +0100 From: "Daniel P. Berrange" Message-ID: <20110523160623.GB24143@redhat.com> References: <20110523130411.GR24143@redhat.com> <4DDA620F.1090308@codemonkey.ws> <20110523134021.GT24143@redhat.com> <4DDA663F.30907@codemonkey.ws> <4DDA7829.5090103@codemonkey.ws> <20110523151948.GJ27503@amd.home.annexia.org> <4DDA7C17.6020208@codemonkey.ws> <20110523152944.GK27503@amd.home.annexia.org> <4DDA8461.2040704@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <4DDA8461.2040704@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: qemu-devel@nongnu.org, Markus Armbruster , "Richard W.M. Jones" , Luiz Capitulino On Mon, May 23, 2011 at 10:59:29AM -0500, Anthony Liguori wrote: > On 05/23/2011 10:29 AM, Richard W.M. Jones wrote: > >On Mon, May 23, 2011 at 10:24:07AM -0500, Anthony Liguori wrote: > >>On 05/23/2011 10:19 AM, Richard W.M. Jones wrote: > >>What I suggested would let us work with any JSON client, but if > >>clients loose precision after 53-bits, those clients would not work > >>well with QEMU. > > > >I totally agree that the JSON "standard" is completely underspecified > >and not very useful (lacking a schema, strong typing, well-specified > >limits). Nevertheless, for better or worse it's what we're using. > > > >There is one very important JSON client we are using called libvirt. > > No, libvirt is a virtualization library. It happens to have a home > grown JSON client but down the road, if there's a nice, common JSON > library and it decides to switch to it, we don't want to have a > bunch of compatibility issues that prevents that from happening. We use the YAJL json library for parsing & formatting JSON. When parsing, it validates that the number is valid according to the JSON grammer, and then passes it without semantic interpretation onto the app using the library. So with YAJL, it is the app (libvirt) which decides the whether to treat this as a float, double, int64, uint64 as appropriate to the context of the JSON document. Regards, 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 :|