[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] QMP; unsigned 64-bit ints; JSON standards compliance

From: Markus Armbruster
Subject: Re: [Qemu-devel] QMP; unsigned 64-bit ints; JSON standards compliance
Date: Mon, 13 May 2019 15:53:19 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)

Daniel P. Berrangé <address@hidden> writes:

> On Wed, May 08, 2019 at 02:44:07PM +0200, Markus Armbruster wrote:
>> Double-checking: do you propose to encode *all* numbers as strings, or
>> just certain "problematic" numbers?
>> If the latter, I guess your idea of "problematic" is "not representable
>> exactly as double precision floating-point".
> We have a few options
>  1. Use string format for values > 2^53-1, int format below that
>  2. Use string format for all fields which are 64-bit ints whether
>     signed or unsigned
>  3. Use string format for all fields which are integers, even 32-bit
>     ones
> I would probably suggest option 2. It would make the QEMU impl quite
> easy IIUC, we we'd just change the QAPI visitor's impl for the int64
> and uint64 fields to use string format (when the right capability is
> negotiated by QMP).
> I include 3 only for completeness - I don't think there's a hugely
> compelling reason to mess with 32-bit ints.


> Option 1 is the bare minimum needed to ensure precision, but to me
> it feels a bit dirty to say a given field will have different encoding
> depending on the value. If apps need to deal with string encoding, they
> might as well just use it for all values in a given field.

I guess that depends on what this interoperability capability does for
QMP *input*.

For *output*, QEMU has to encode a number either as JSON number or as
JSON string

For *input*, QEMU could accept either.  Or it could accept only the
encoding it produces on output.

Got a preference?

>> You wrote Jansson "raises a fatal parse error for unsigned 64-bit values
>> above 2^63-1".  Does that mean it rejects 9223372036854775808, but
>> accepts 9223372036854775808.0 (with loss of precision)?
> If it sees a '.' in the number, then it call strtod() and checks for
> the overflow conditions.
> If it doesn't see a '.' in the number then it calls strtoll and checks
> for the overflow conditions.
> So to answer you question, yes, it looks like it will reject
> 9223372036854775808 and accept 9223372036854775808.0 with loss of
> precision.

Sucks :)

But then JSON does.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]