On Mon, May 13, 2019 at 03:53:19PM +0200, Markus Armbruster wrote: > Daniel P. Berrangé <berrange@xxxxxxxxxx> 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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
