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]."
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.
The alternative approach is to be conservative and only use 32-bit
integers and represent everything in two numbers.
Regards,
Anthony Liguori
Rich.
