On Mon, May 13, 2019 at 03:53:19PM +0200, Markus Armbruster wrote:
Daniel P. Berrangé <berrange@redhat.com> 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.
Agree.
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?
IMHO if a mgmt app enables the (hypothetically named) "int64-as-string" capability, then we should be strict and require string format on both input & output. If QEMU accepted either, it would silently hide bugs where the app has mistakenly not used string formatting. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|