From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:32872) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c9AOJ-0004M8-ES for qemu-devel@nongnu.org; Tue, 22 Nov 2016 07:41:40 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c9AOG-0003Q4-AK for qemu-devel@nongnu.org; Tue, 22 Nov 2016 07:41:39 -0500 Received: from mx1.redhat.com ([209.132.183.28]:58834) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1c9AOG-0003OC-0C for qemu-devel@nongnu.org; Tue, 22 Nov 2016 07:41:36 -0500 References: <673F175E-AF65-4F4F-9895-C7335A36AC29@gmail.com> <8b136de6-490a-d194-b7a6-eabfb87daf2c@redhat.com> <16AF327F-E1FE-4F2E-9919-A474276474FF@gmail.com> <182f25fb-98bd-73db-62f3-ff18b30a49cd@redhat.com> <3c5fdd4e-da35-46d9-9c64-a1a269f41646@redhat.com> <87twaz3k2h.fsf@dusky.pond.sub.org> From: Eric Blake Message-ID: Date: Tue, 22 Nov 2016 06:41:33 -0600 MIME-Version: 1.0 In-Reply-To: <87twaz3k2h.fsf@dusky.pond.sub.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="buSbHSi0PxSRU36xjp61jVFfldLKbkaPj" Subject: Re: [Qemu-devel] qobject/qjson.c:69: failed assertion `obj != NULL' List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: G 3 , Paolo Bonzini , qemu-devel qemu-devel This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --buSbHSi0PxSRU36xjp61jVFfldLKbkaPj From: Eric Blake To: Markus Armbruster Cc: G 3 , Paolo Bonzini , qemu-devel qemu-devel Message-ID: Subject: Re: [Qemu-devel] qobject/qjson.c:69: failed assertion `obj != NULL' References: <673F175E-AF65-4F4F-9895-C7335A36AC29@gmail.com> <8b136de6-490a-d194-b7a6-eabfb87daf2c@redhat.com> <16AF327F-E1FE-4F2E-9919-A474276474FF@gmail.com> <182f25fb-98bd-73db-62f3-ff18b30a49cd@redhat.com> <3c5fdd4e-da35-46d9-9c64-a1a269f41646@redhat.com> <87twaz3k2h.fsf@dusky.pond.sub.org> In-Reply-To: <87twaz3k2h.fsf@dusky.pond.sub.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 11/22/2016 04:06 AM, Markus Armbruster wrote: > Eric Blake writes: >=20 >> On 11/21/2016 02:36 PM, Eric Blake wrote: >>> The source of your problem is that your platform defines PRId64 as 'q= d', >>> but the qemu JSON parser only recognizes lld (POSIX) or I64d (mingw) = for >>> parsing 64-bit numbers. We could enhance the JSON parser to recogniz= e >>> the non-standard qd in addition to the hack we already have for mingw= , >=20 > Yes... >=20 >>> but I'd argue that using qobject_from_jsonf() is already less-than-us= eful. >> >> In fact, we are down to only a handful of users of our modified 'jsonf= ' >> format (that is, strings that mix JSON with % modifiers): >> >> hw/pci/pcie_aer.c: build a 5-element QDict >> monitor.c: build a 1-element QDict which contains a 2-element QDict >> qapi/qmp-dispatch.c: build a 2-element QDict >> qapi/qmp-event.c: Build a 2-element QDict >> >> plus the testsuite (check-qjson.c). >=20 > How did you find them? git grep qobject_from_jsonf I forgot about qobject_from_jsonv(), which is a bit more pervasive in the testsuite, but even there, I only found a few additional uses of % (that time, found by adding an assert(!strchr(format, '%')), then seeing where it triggered during 'make check'). I should have the cleanup series later today. Technically, avoiding PRId64 in qmp-event.c is worth having in 2.8 (it's a bug fix for Mac OS); but the rest of the series is 2.9 material. Note that at least one of the testsuite conversions I'm making also used PRId64 - is the original poster even running 'make check', as at least check-qga would be evidence of the JSON parser failing to understand Mac's %qd. >=20 >>> It's hard to argue that the >>> complexity of maintaining our pseudo-printf JSON parser for construct= ing >>> a QObject with one line is worth the effort compared to the three or >>> four lines to construct the same QObject by hand. >> >> I'm severely tempted to just rip out all of the poorly-underdocumented= % >> parsing from the JSON parser, as it will simplify our code, without mu= ch >> pain in converting the four real users to just manually build up the >> same objects. >=20 > I kind of like the %-escapes, because they provide a compact and legibl= e > way to build QObjects. But with so little use, they're hardly earning > their keep. What drives me most insane about them is that they are NOT the same escapes as printf(), so the compiler can't help us with type safety, and things like PRId64 don't always do what we want. And except for %p for injecting nested objects, most of our escapes are just as easy to perform with g_strdup_printf() (injecting a string, integer, or boolean), or by manual creation of the QDict. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --buSbHSi0PxSRU36xjp61jVFfldLKbkaPj 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/ iQEcBAEBCAAGBQJYNDz9AAoJEKeha0olJ0NqNRIIAKbX5p9a8yvr/r3CuNQhLTP2 NxeJz6X3Z/o/2dvTogoa5WPYKxNYorr/wEXQbgjdHwexa4TTweWSxLPgngQ3IYQa POEJIbMo0p0sw5uSqiAfluVbjWJE7Z03NkMwCx8YL/yoT5Yk2yAyiRGgwFBmc5d9 3x/nRzqjVs9Um6NgkcYrWcz3nJ917p1u4Gl4STZGHT5N1JEK4eqQAjGTGBxU70Li SLpqvcip2PfNzZJYRTQUiFWWDqztu1XxmeVCNZ5lxhsrTjcZ5TNMqIOAjo+iPp2c sXGNccgNSEDzhR8txhBrip+2Db+S8QlBkTLGUFUU9Mcfy/saiJvj2K3o+lwO5KE= =3bos -----END PGP SIGNATURE----- --buSbHSi0PxSRU36xjp61jVFfldLKbkaPj--