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
