From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:46051) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QOY8Z-00042W-22 for qemu-devel@nongnu.org; Mon, 23 May 2011 12:37:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QOY8Y-00010x-3u for qemu-devel@nongnu.org; Mon, 23 May 2011 12:37:47 -0400 Received: from mail-gx0-f173.google.com ([209.85.161.173]:37009) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QOY8X-00010o-Vv for qemu-devel@nongnu.org; Mon, 23 May 2011 12:37:46 -0400 Received: by gxk26 with SMTP id 26so2571581gxk.4 for ; Mon, 23 May 2011 09:37:45 -0700 (PDT) Message-ID: <4DDA8D56.4020302@codemonkey.ws> Date: Mon, 23 May 2011 11:37:42 -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> <4DDA7C17.6020208@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 , qemu-devel@nongnu.org, "Richard W.M. Jones" On 05/23/2011 11:18 AM, Markus Armbruster wrote: > Anthony Liguori writes: > >> 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. > > A client is allowed to represent numbers however it sees fit. Even > fixed-point BCD. The RFC doesn't specify minimal limits. I think there's a point being lost in the discussion. Consider a QMP function called identity(x) that just returns it's argument. Here's what's fundamentally at question: identity(1) -> 1 // goodness identity(NaN) -> #Exception // goodness identity(int64_max) -> int64_max // goodness identity(int64_max) -> rnd_to_52_bits(int64_max) // goodness identity(int64_max + 1) -> rnd_to_52_bits(int64_max + 1) // goodness identity(int64_max + 1) -> int64_t max + 1 // goodness identity(int64_max + 1) -> -1 // badness JSON does not distinguish between integers and floating point numbers. It's behaviors with respect to overflow of whatever the defined representation is should not be integer overflow but IEEE rounding. I would further argue that a conforming client/server guarantees *at least* double precision floating point accuracy. Additional would be allowed providing that the additional accuracy meets the rounding rules of IEEE. So for instance, you can use an 80-bit floating point number to do your math and send string representations of the 80-bit number (because the conversion should give you the same results within the expected accuracy). Regards, Anthony Liguori