Anthony Liguori <anth...@codemonkey.ws> writes: > 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]."
"derived from" != "identical with". JSON is *syntax*. Numerical limits are outside its scope. >> 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. A client is allowed to represent numbers however it sees fit. Even fixed-point BCD. The RFC doesn't specify minimal limits. > Fundamentally, we need to ask ourselves, do we want to support any > JSON client or require JSON libraries explicitly written for QEMU? Simple: we require a JSON library that can represent 64 bit integers faithfully. Those aren't exactly in short supply. > 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. That's a fair guess of what any of today's JSON libraries should be able to represent, but it's not conservative.
