From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:42537) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QOWj9-00074m-DY for qemu-devel@nongnu.org; Mon, 23 May 2011 11:07:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QOWj5-0006zb-Dn for qemu-devel@nongnu.org; Mon, 23 May 2011 11:07:27 -0400 Received: from mail-yi0-f45.google.com ([209.85.218.45]:43030) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QOWj5-0006zX-9R for qemu-devel@nongnu.org; Mon, 23 May 2011 11:07:23 -0400 Received: by yib19 with SMTP id 19so2505772yib.4 for ; Mon, 23 May 2011 08:07:23 -0700 (PDT) Message-ID: <4DDA7829.5090103@codemonkey.ws> Date: Mon, 23 May 2011 10:07:21 -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> In-Reply-To: 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: Markus Armbruster Cc: Luiz Capitulino , "Richard W.M. Jones" , qemu-devel@nongnu.org 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. Regards, Anthony Liguori >