From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55515) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bDZzJ-0003fd-5F for qemu-devel@nongnu.org; Thu, 16 Jun 2016 12:17:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bDZzE-0001EJ-U4 for qemu-devel@nongnu.org; Thu, 16 Jun 2016 12:17:48 -0400 Received: from mx1.redhat.com ([209.132.183.28]:40205) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bDZzE-0001EA-OB for qemu-devel@nongnu.org; Thu, 16 Jun 2016 12:17:44 -0400 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (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 4D03280083 for ; Thu, 16 Jun 2016 16:17:44 +0000 (UTC) From: Markus Armbruster References: <1465526889-8339-1-git-send-email-eblake@redhat.com> <1465526889-8339-5-git-send-email-eblake@redhat.com> Date: Thu, 16 Jun 2016 18:17:41 +0200 In-Reply-To: <1465526889-8339-5-git-send-email-eblake@redhat.com> (Eric Blake's message of "Thu, 9 Jun 2016 20:48:09 -0600") Message-ID: <87inx9w1ju.fsf@dusky.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain 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: Eric Blake Cc: qemu-devel@nongnu.org, Luiz Capitulino Eric Blake writes: > 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. 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. 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. > Of course, as long as we don't recognize (certain) strings as valid > numbers during a conversion to QObject, That would be even crazier! > 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 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. 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: * Object q_obj_migrate_set_downtime-arg member value: input * Builtin number: d'uh! * Object MigrationStats member mbps: in output of query-migrate * Object XBZRLECacheStats member overflow: likewise * Object KeyValue case number: not a type. * Object BlockDeviceTimedStats members avg_rd_queue_depth, avg_wr_queue_depth: in output of query-blockstats * Enum CommandLineParameterType member: not a type * Enum JSONType member: not a type * Enum KeyValueKind: not a type * Object PciBusInfo member: not a type So it's just query-migrate and query-blockstats.