From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43973) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bDk6y-0006oD-Mw for qemu-devel@nongnu.org; Thu, 16 Jun 2016 23:06:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bDk6v-0005vG-Bf for qemu-devel@nongnu.org; Thu, 16 Jun 2016 23:06:24 -0400 Received: from resqmta-po-09v.sys.comcast.net ([2001:558:fe16:19:96:114:154:168]:53857) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bDk6v-0005vA-3h for qemu-devel@nongnu.org; Thu, 16 Jun 2016 23:06:21 -0400 References: <1465526889-8339-1-git-send-email-eblake@redhat.com> <1465526889-8339-5-git-send-email-eblake@redhat.com> <87inx9w1ju.fsf@dusky.pond.sub.org> From: Eric Blake Message-ID: <57636921.6020303@redhat.com> Date: Thu, 16 Jun 2016 21:06:09 -0600 MIME-Version: 1.0 In-Reply-To: <87inx9w1ju.fsf@dusky.pond.sub.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="0Sf7cxLstd9mSwhWEhMpJAEPONrkuk9q0" Subject: Re: [Qemu-devel] [PATCH 4/4] qobject: Output valid JSON for non-finite numbers 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) --0Sf7cxLstd9mSwhWEhMpJAEPONrkuk9q0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 06/16/2016 10:17 AM, Markus Armbruster wrote: > Eric Blake writes: >=20 >> It's better to give downstream clients a valid JSON string, >> even if they are semantically expecting a number, than it is >> to give them a bare keyword extension that can cause a >> lexical error. >=20 > Incompatible change. If all clients are choking on non-finite numbers,= > then the incompatibility is an improvement. If a client exists that > groks non-finite numbers, ... Absence is always hard to show. The 'id' field is an outlier - there, we replay the user's input with no contextual interpretation (however, we DO reserve the right to reorder the keys in the dicts that we replay, and to canonicalize UTF-8 text or otherwise alter their input to something "equivalent"). >=20 > Moreover, it turns query-qmp-schema into a liar: the schema it returns > claims a certain member of the reply has "type": "number", and then we > go on to send a string anyway. The 'id' field is documented as sending ANY JSON value, so if we argue that canonicalizing their extension input of a bare inf into a proper JSON string on output is reasonable, then we may want this patch in addition to adding assertions that none of the QMP commands with introspectible 'number' ever output non-finite values. >=20 >> Of course, as long as we don't recognize (certain) strings as valid >> numbers during a conversion to QObject, >=20 > That would be even crazier! >=20 >> this means our extension >> of accepting bare keywords for non-finite numbers cannot undergo >> a round trip (once converted into a string, we never get back to >> a QFloat). However, non-finite input is rare enough that it's >> not worth bothering with at the moment. >> >> Signed-off-by: Eric Blake >=20 > I'm afraid the only sane solution is to find all uses of number in QMP > output, audit the code producing them, then assert isfinite() in the > monitor. For commands without a side effect, we could fail the command= > instead of tripping an assertion. We'd have to declare such commands. >=20 > Let's examine the occurences of "number" in output of query-qmp-schema,= > or actually in the qmp-introspect.c that gets generated with -u: >=20 > * Object q_obj_migrate_set_downtime-arg member value: input Even though it's not output, it does need to be checked that it will behave sanely with Inf or NaN input if we extend our parser to allow those (behaving sanely may include a graceful error that the input was out of range). >=20 > * Builtin number: d'uh! >=20 > * Object MigrationStats member mbps: in output of query-migrate >=20 > * Object XBZRLECacheStats member overflow: likewise >=20 > * Object KeyValue case number: not a type. >=20 > * Object BlockDeviceTimedStats members avg_rd_queue_depth, > avg_wr_queue_depth: in output of query-blockstats >=20 > * Enum CommandLineParameterType member: not a type >=20 > * Enum JSONType member: not a type >=20 > * Enum KeyValueKind: not a type >=20 > * Object PciBusInfo member: not a type >=20 > So it's just query-migrate and query-blockstats. >=20 Okay, looks like I need to respin this, and the rest of my JSON output visitor on top of it, with this audit done first. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --0Sf7cxLstd9mSwhWEhMpJAEPONrkuk9q0 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/ iQEcBAEBCAAGBQJXY2khAAoJEKeha0olJ0Nqw0IH/0HeFHvkPiJKjTSJLnLE89eY 4JK5LRpwdgC7tZYgLW4kiSrq5X/U2z8EqnnqnWaZONPOrs/lxaGDW6bk82fHxu+Z +FboQ/+WAw/Jdlg1LldBVf8YUdSXdB8RQ6/qUiZHsLtoupsGdBbivFcT7+C3HE6D OV9bknwZGq16+HdpLeVE/naT6mVcLglaEZWgqeoh/AC5nFOUSRCApWT4ryZRlC40 hNZUHXxWvXG8H8CJawyjjKu/q5foF/8kNdbOzyPxkK/D7KyJPO2f927nhuNrUe9+ K/iXbbH4r7lrJ2mGtuhSW0vTHd4O0ZabULLZ4IO/pgMqn7HCxaap59nYHhccaGM= =D4hS -----END PGP SIGNATURE----- --0Sf7cxLstd9mSwhWEhMpJAEPONrkuk9q0--