qemu-block
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] schemas: Add vim modeline


From: Markus Armbruster
Subject: Re: [PATCH] schemas: Add vim modeline
Date: Mon, 03 Aug 2020 17:48:35 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)

Daniel P. Berrangé <berrange@redhat.com> writes:

> 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.

You know, if I had to write a *general purpose* parser for a language
that obviously supports numbers of arbitrary precision (but permits
implementations to support less), then I'd try *hard* to stay as general
as practical.  At the very least, provide a way to retrieve number
tokens as strings, so the decision to limit precision devolves to the
client.  Also, GMP exists.

The fact that "most viable alternatives" to YAJL are unable to support
uint64_t tempts me to condemn the whole lot as toys :)

I suspect the simplicity of JSON not only lowers the barrier for toys,
but also dampens the demand for general purpose non-toys.  Writing and
maintaining yet another JSON parser is quite possibly easier than
getting one of the toys fixed up properly.

[...]




reply via email to

[Prev in Thread] Current Thread [Next in Thread]