On Mon, Aug 03, 2020 at 02:16:19PM +0200, Paolo Bonzini wrote: > On 03/08/20 13:36, Daniel P. Berrangé wrote: > >>> Given that QEMU needs to pass > >>> uint64 values, JSON was simply the wrong choice of format for QMP. > > > > I wasn't refering to RFC7159. The problem of undefined integer precision > > with JSON came up right at the very start when QMP was first designed and > > implemented, and has come up again periodically ever since then. libvirt > > needed to do workarounds right at the start in 2009, in order to fully > > handle signed/unsigned 64-bit integers with QMP. > > I assume the workaround you refer to is to store the number as a string > and converting it lazily to either an integer or a floating-point type > in whoever uses the JSON API. It may not be pretty but probably it > would have been the same for any text-based, schema-less protocol. For > example, it didn't require writing your own parser.
Yes, we get the raw values as a string, but not all parsers for C allow you to do this. We'd really love to move off YAJL for JSON parsing, but the most viable alternatives don't have a way to let you get the string before they parse it as an integer and report errors. > It could be avoided by using a schema in Libvirt, just like QEMU has no > problem with it on the other side; it's just a different design choice > with different trade-offs, I don't think it's enough of an issue to > declare JSON "the wrong choice of format for QMP". The schema doesn't help - the problem is many JSON parsers don't allow use of full uint64 values when parsing - alot will simply report an error for anything bigger than LLONG_MAX and offer no workaround. 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 :|
