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

[Daniel P. Berrange]

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]."
> 
> >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?

We just need to clarify what we mean by 'support' here. Any JSON
compliant client can talk to the QEMU monitor, but some JSON clients
may be better than others. So we just need state:

 - QEMU is compatible with any JSON client.
 - QEMU recommends use of JSON clients that can represent
   integers with a minimum precision of 64-bits.

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

Yep, if clients loose precision after 53-bits that's fine, just an
app problem. The key factor is that QEMU must not be the one throwing
away precision.

Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|