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<anth...@codemonkey.ws> 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/
