Re: [Qemu-devel] [PATCH] qemu: json: Fix parsing of integers >= 0x8000000000000000

[Anthony Liguori <anthony@codemonkey.ws>]

On 05/23/2011 11:18 AM, Markus Armbruster wrote:
> Anthony Liguori<anthony@codemonkey.ws>  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