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