From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37889) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bB2U7-0001s7-6m for qemu-devel@nongnu.org; Thu, 09 Jun 2016 12:07:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bB2U1-0007ME-P1 for qemu-devel@nongnu.org; Thu, 09 Jun 2016 12:07:06 -0400 Received: from mx1.redhat.com ([209.132.183.28]:41119) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bB2U1-0007M8-G2 for qemu-devel@nongnu.org; Thu, 09 Jun 2016 12:07:01 -0400 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (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 028BC63309 for ; Thu, 9 Jun 2016 16:07:01 +0000 (UTC) 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> From: Eric Blake Message-ID: <57599424.7080308@redhat.com> Date: Thu, 9 Jun 2016 10:07:00 -0600 MIME-Version: 1.0 In-Reply-To: <87twha3as9.fsf@dusky.pond.sub.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ht5v9XdA1iXlNEtlJMtF87UkjMiNkWpfx" 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: Markus Armbruster Cc: qemu-devel@nongnu.org, Luiz Capitulino This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ht5v9XdA1iXlNEtlJMtF87UkjMiNkWpfx Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 06/03/2016 03:02 AM, Markus Armbruster wrote: >>> Suggest: >>> >>> * Return 0 if the number is finite, as required by RFC 7159, else -1= =2E >>> >>> The return value makes some sense only for symmetry with >>> qstring_append_json_string(). Without that, I'd ask you to keep this= >>> function simple. Callers could just as easily test isfinite() >>> themselves. >> >> I'm actually thinking of modifying this, given the recent thread >> pointing out that libvirt chokes hard on JSON extensions: >> >> https://lists.gnu.org/archive/html/qemu-devel/2016-05/msg04398.html >> >> That is, for symmetry with qstring_append_json_string(), I'm thinking = of >> changing NaN to 0 and Inf to DBL_MAX, and always outputting a finite >> value, in addition to returning -1 to inform the caller that a >> substitution was made, so that the output is always strict JSON. >=20 > Mapping infinities to DBL_MIN and DBL_MAX is debatable, but mapping NaN= > to zero is outright wrong. How about this alternative: Finite values remain numbers: "number":1 But non-finite values are output as strings, so that our output is always valid JSON - the recipient may not be expecting a string in place of a number, but at least should be able to parse the output rather than choking hard. "number":"nan" The return value -1 then indicates that a stringized replacement was used, so that any later patch can use a strict flag on whether to allow the replacement output or assert. >=20 > If we decide QMP should stick to JSON here and avoid non-finite numbers= , > we need to treat an attempt to emit a non-finite number as a bug: > assert(isfinite(...)). Making sure nothing ever attempts to emit such > numbers will be tedious. >=20 > If we decide QMP should remain as it is, we need to document non-finite= > numbers among its JSON extensions. We should also fix our QMP parsers > to accept non-finite numbers then. Including the one in libvirt. > Attempts to emit non-finite numbers then *may* be bugs. Really no > different than finite numbers outside their intended range, such as a > negative size. Catching these bugs is of course also tedious. The > difference is that they manifest in QMP as semantic instead of lexical > errors. Lexical errors are the worst to handle gracefully. 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) - 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). But with my proposal of producing a stringized non-finite value, we at least convert lexical into semantic errors, which I agree with your assessment is a nicer way of dealing with it. Of course, a policy change of outputting stringized non-finite numbers should be separate from refactoring patches that just move functions arou= nd. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --ht5v9XdA1iXlNEtlJMtF87UkjMiNkWpfx Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJXWZQkAAoJEKeha0olJ0Nqog4H/0r447c5YECnvSIU+ifblv8C kf+aCRBthdeaaFnvOXCwdMdcg85mHm7SOncwJ0kYxXT1AXuxy7mnTQqcx6MuMg9X Xgv8p83DeqdWv1YpRCjI4JbUSAoSJNC/luo6zogl+U/Xcx2oRH4HtziKD8NMTdqP TkEuF29E60jwNYhSY5V88HgT73/H80FSzezL+POJn9kyidq+ScMCj4wi7CnvMGay vzxaBS6K1wHg1cjO+sorDMvp8cLO4axCyfB5V3cDG4fqs/+qI70xMWiIqWIR61vU V8tdB08qnEAaMzkcmK3ZuJOdzHO3WlLC7MB4LATcOnS1NRPHCaRe5vai0YjUK4E= =5R9T -----END PGP SIGNATURE----- --ht5v9XdA1iXlNEtlJMtF87UkjMiNkWpfx--