|
From: | Anthony Liguori |
Subject: | Re: [Qemu-devel] [PATCH] qemu: json: Fix parsing of integers >= 0x8000000000000000 |
Date: | Mon, 23 May 2011 11:37:42 -0500 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10 |
On 05/23/2011 11:18 AM, Markus Armbruster wrote:
Anthony Liguori<address@hidden> 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 // badnessJSON 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
[Prev in Thread] | Current Thread | [Next in Thread] |