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? [...]
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.