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

[Eric Blake]

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.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature