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? [...] >> 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. -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
