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

[Markus Armbruster]

Anthony Liguori <address@hidden> 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<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]."

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