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

On 5/13/19 8:53 AM, Markus Armbruster wrote: 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. "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, 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). 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