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

[Markus Armbruster]

Anthony Liguori <address@hidden> writes:

> 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                              // badness

That's one workable numerical semantics.  There are others.

I don't follow your jump from JSON (a somewhat underspecified data
exchange format) to "QMP function" (a somewhat unspecified programming
language).

> JSON does not distinguish between integers and floating point
> numbers.

Correct.

>          It's behaviors with respect to overflow of whatever the
> defined representation is should not be integer overflow but IEEE
> rounding.

Citation needed.

> 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.

Conforming to what?  The RFC does not specify anything on the
interpretation of the syntactic entity "number".

You fill that gap by falling back to JavaScript, on the theory that
"derived from JavaScript" implies "all gaps in this RFC to be filled
from JavaScript".  Not only is that theory debatable, it also needs to
face the test of existing practice.  It fails that test.

Here's a more or less random pick from the real world:
http://deron.meranda.us/python/comparing_json_modules/numbers

    About JSON numbers

    It is important to realize that JSON only specifies the syntax for
    writing numerals in decimal notation, and does not deal with any
    semantics or meanings of actual numbers.  JSON does not distinguish
    types, such as integer or floating point.  Nor does JSON impose any
    size or precision limits on the numbers it can represent.

and

    Converting Python numbers to JSON

    Integral types

    Python integral types (int and long) should be convertable directly
    to JSON.  Since JSON imposes no size limits all Python integers can
    be represented by JSON; however, remember that many other JSON
    implementations in other languages may not be able to handle these
    large numbers.

> 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).

You can also drill a hole into your knee and fill it with milk.

Look, JSON is just syntax.  It intentionally leaves assigning meaning to
the application.  This includes choice of numerical limits, as the RFC
clearly states.

The application QEMU needs to declare applicable numerical limits.
Clients ignore them at their own risk.  End of story.

Of course the application is free to twist its use of JSON into
unnatural contortions like sending numbers as strings (sometimes or
always), or splitting them apart.  This may make a few more JSON
implementations compatible with the application.  It also makes it
harder to build the interesting stuff on top of the JSON implementation.

In the case of QMP, that's a bad tradeoff.  More so, since it would
break the one known client: libvirt.  Which had no trouble whatsoever
finding a JSON implementation compatible with QMP's numerical limits.