Re: [Qemu-devel] [PATCH v4 17/28] qapi: Factor out JSON number formatting

[Markus Armbruster <armbru@redhat.com>]

Eric Blake <eblake@redhat.com> writes:

> On 06/13/2016 02:22 AM, Markus Armbruster wrote:
>
>>> I may still try to tackle fixing the QMP parser to accept NaN and
>>> infinity on input (since it's hand-written, we at least have control
>>> over that)
>> 
>> Making json-lexer.c recognize infinities and NaNs in strtod() syntax
>> shouldn't be hard.  I'd omit nan(n-char-sequence-opt), because its
>> semantics are implementation defined.  I'd also omit all spellings other
>> than inf and nan.  That leaves inf, +inf, -inf, nan, +nan, -nan.
>
> +inf and +nan weren't worth it (JSON doesn't accept +0 either), but
> '-inf' and '-nan' were easy.  In fact, '-infinity' was easy too - see
> the posted patches:
> https://lists.gnu.org/archive/html/qemu-devel/2016-06/msg02652.html
> and you are right that it was not worth 'nan(n-char-seq)'.
>
>> 
>>>            - it will certainly be easier than getting libvirt to parse
>>> non-finite numbers (libvirt uses libyajl, and my emails to the yajl
>>> mailing list have gone unanswered, making me think the project is not
>>> very vibrant and thus not very patchable).
>> 
>> Nobody likes to carry downstream patches, but an unresponsive upstream
>> may leave you no choice.
>
> Another (possibly-ugly) option that I thought of over the weekend: We
> have 'qmp_capabilities' for handshakes between client and server.  The
> server could advertise a new capability 'nonfinite' in its initial
> greeting, and if the client replies with the same capability, then the
> server knows that the client is prepared to accept bareword non-finite
> numbers.  A client that doesn't see the server advertise anything has no
> guarantees, and a server that knows the capability but doesn't see the
> client request the capability should avoid sending bareword non-finite.

The capability negotiation mechanism exists to support things like that.
However, the problem what to do when the command reply contains
non-finite numbers remains.  A capability can at best hide whatever ugly
solution we have for that, and perhaps help us get rid of it in an
orderly fashion eventually, by refusing to talk to clients that don't
accept the capability.

Moreover, we're already sending non-finite numbers!  Changing QMP to
send something else unless the client opts into non-finite numbers via
capability "nonfinite" is an incompatible change.  We could weasel out
of that by declaring our sending of them a bug, then turn around and
declare it a feature when capability "nonfinite" is accepted.  Meh.