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

[Richard W.M. Jones]

On Mon, May 23, 2011 at 10:24:07AM -0500, Anthony Liguori wrote:
> On 05/23/2011 10:19 AM, Richard W.M. Jones wrote:
> >On Mon, May 23, 2011 at 10:07:21AM -0500, Anthony Liguori wrote:
> >>On 05/23/2011 09:29 AM, Markus Armbruster wrote:
> >>>Anthony Liguori<address@hidden>   writes:
> >>>
> >>>JavaScript's implementation of JSON sets limits on the range of numbers,
> >>>namely they need to fit into IEEE doubles.
> >>>
> >>>Our implementation sets different limits.  IIRC, it's something like
> >>>"numbers with a fractional part or an exponent need to fit into IEEE
> >>>doubles, anything else into int64_t."  Not exactly the acme of elegance,
> >>>either.  But it works for us.
> >>
> >>In order to be compatible with JavaScript (which I think is
> >>necessary to really satisfy the spec), we just need to make sure
> >>that our integers are represented by at least 53-bits (to enable
> >>signed integers) and critically, fall back to floating point
> >>representation to ensure that we round instead of truncate.
> >
> >The problem is to be able to send 64 bit memory and disk offsets
> >faithfully.  This doesn't just fail to solve the problem, it's
> >actually going to make it a whole lot worse.
> >
> >I don't agree with you that whatever the JSON standard (RFC) doesn't
> >specify must be filled in by reading Javascript/ECMA.
> 
> "  It is derived from the object
>    literals of JavaScript, as defined in the ECMAScript Programming
>    Language Standard, Third Edition [ECMA]."

I don't think this is anything other than advice or background
about the standard.

> >If this is so
> >important, it's very odd that it doesn't mention this fallback in the
> >RFC.  If you read the RFC alone then it's pretty clear (to me) that it
> >leaves limits up to the application.
> 
> 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.
> 
> Fundamentally, we need to ask ourselves, do we want to support any
> JSON client or require JSON libraries explicitly written for QEMU?
> 
> What I suggested would let us work with any JSON client, but if
> clients loose precision after 53-bits, those clients would not work
> well with QEMU.

I totally agree that the JSON "standard" is completely underspecified
and not very useful (lacking a schema, strong typing, well-specified
limits).  Nevertheless, for better or worse it's what we're using.

There is one very important JSON client we are using called libvirt.

> The alternative approach is to be conservative and only use 32-bit
> integers and represent everything in two numbers.

Or use strings ...

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://et.redhat.com/~rjones/virt-df/