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

[Eric Blake]

On 5/13/19 8:53 AM, Markus Armbruster wrote:

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

Other than if we ever change the type of a QMP integer. Right now, if we
widen from 'int32' to 'int' (aka 'int64'), it is invisible to clients;
but once we start stringizing 64-bit numbers (at client request) but NOT
32-bit numbers, then changing a type from 32 to 64 bits (or the
converse) becomes an API change to clients. Introspection will at least
let a client know which form to expect, but it does mean we have to be
more aware of typing issues going forward.

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

"Be liberal in what you accept, strict in what you produce" - that
argues we should accept both forms on input (it's easy enough to ALWAYS
permit a string in place of an integer, and to take an in-range integer
even when we would in turn output it as a string).

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

For output, we should document that whatever capability the client
passes in at initial connect controls the behavior of all future integer
outputs (and if no capability is negotiated, we output all integers as
integers, even if it risks overflowing the client's JSON parser).

> 
> For *input*, QEMU could accept either.  Or it could accept only the
> encoding it produces on output.
> 
> Got a preference?
> 

My ramblings above argue to teach the parser to always allow both
integer and string forms regardless of width, to output 32-bit integers
as integers, and to output 64-bit integers as string-only (if capability
is negotiated) or as integer-only (if in back-compat mode).

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20190513/3c4e6ae6/attachment-0001.sig>