From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:43199) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QOWzL-0002Yy-Qy for qemu-devel@nongnu.org; Mon, 23 May 2011 11:24:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QOWzK-0001dL-Ke for qemu-devel@nongnu.org; Mon, 23 May 2011 11:24:11 -0400 Received: from mail-gx0-f173.google.com ([209.85.161.173]:59444) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QOWzK-0001dF-IK for qemu-devel@nongnu.org; Mon, 23 May 2011 11:24:10 -0400 Received: by gxk26 with SMTP id 26so2524646gxk.4 for ; Mon, 23 May 2011 08:24:09 -0700 (PDT) Message-ID: <4DDA7C17.6020208@codemonkey.ws> Date: Mon, 23 May 2011 10:24:07 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <20110520180331.GA21837@amd.home.annexia.org> <4DD6AEB9.6060506@codemonkey.ws> <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> In-Reply-To: <20110523151948.GJ27503@amd.home.annexia.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] qemu: json: Fix parsing of integers >= 0x8000000000000000 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Richard W.M. Jones" Cc: qemu-devel@nongnu.org, Markus Armbruster , Luiz Capitulino On 05/23/2011 10:19 AM, Richard W.M. Jones wrote: > On Mon, May 23, 2011 at 10:07:21AM -0500, Anthony Liguori wrote: >> On 05/23/2011 09:29 AM, Markus Armbruster wrote: >>> Anthony Liguori writes: >>> >>> JavaScript's implementation of JSON sets limits on the range of numbers, >>> namely they need to fit into IEEE doubles. >>> >>> Our implementation sets different limits. IIRC, it's something like >>> "numbers with a fractional part or an exponent need to fit into IEEE >>> doubles, anything else into int64_t." Not exactly the acme of elegance, >>> either. But it works for us. >> >> In order to be compatible with JavaScript (which I think is >> necessary to really satisfy the spec), we just need to make sure >> that our integers are represented by at least 53-bits (to enable >> signed integers) and critically, fall back to floating point >> representation to ensure that we round instead of truncate. > > The problem is to be able to send 64 bit memory and disk offsets > faithfully. This doesn't just fail to solve the problem, it's > actually going to make it a whole lot worse. > > I don't agree with you that whatever the JSON standard (RFC) doesn't > specify must be filled in by reading Javascript/ECMA. " It is derived from the object literals of JavaScript, as defined in the ECMAScript Programming Language Standard, Third Edition [ECMA]." > If this is so > important, it's very odd that it doesn't mention this fallback in the > RFC. If you read the RFC alone then it's pretty clear (to me) that it > leaves limits up to the application. If it's left up to the application, doesn't that mean that we can't ever send 64-bit memory/disk faithfully? Because a client would be allowed to represent integers as signed 32-bit numbers. Fundamentally, we need to ask ourselves, do we want to support any JSON client or require JSON libraries explicitly written for QEMU? 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. The alternative approach is to be conservative and only use 32-bit integers and represent everything in two numbers. Regards, Anthony Liguori > > Rich. >