From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52865) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bCT3O-0005I2-O8 for qemu-devel@nongnu.org; Mon, 13 Jun 2016 10:41:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bCT3J-0007bv-UQ for qemu-devel@nongnu.org; Mon, 13 Jun 2016 10:41:26 -0400 Received: from mx1.redhat.com ([209.132.183.28]:33163) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bCT3J-0007bq-Mn for qemu-devel@nongnu.org; Mon, 13 Jun 2016 10:41:21 -0400 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 4AF5B8F4F2 for ; Mon, 13 Jun 2016 14:41:21 +0000 (UTC) From: Markus Armbruster References: <1463632874-28559-1-git-send-email-eblake@redhat.com> <1463632874-28559-18-git-send-email-eblake@redhat.com> <8737oveirs.fsf@dusky.pond.sub.org> <57504B76.7040309@redhat.com> <87twha3as9.fsf@dusky.pond.sub.org> <57599424.7080308@redhat.com> <87vb1dqz01.fsf@dusky.pond.sub.org> <575EA864.4040406@redhat.com> Date: Mon, 13 Jun 2016 16:41:19 +0200 In-Reply-To: <575EA864.4040406@redhat.com> (Eric Blake's message of "Mon, 13 Jun 2016 06:34:44 -0600") Message-ID: <874m8xtals.fsf@dusky.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Qemu-devel] [PATCH v4 17/28] qapi: Factor out JSON number formatting List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: qemu-devel@nongnu.org, Luiz Capitulino Eric Blake 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.