From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48841) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zqka3-0004nb-KH for qemu-devel@nongnu.org; Mon, 26 Oct 2015 12:25:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZqkZy-000053-MX for qemu-devel@nongnu.org; Mon, 26 Oct 2015 12:25:07 -0400 Received: from mx1.redhat.com ([209.132.183.28]:41920) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZqkZy-00004s-F4 for qemu-devel@nongnu.org; Mon, 26 Oct 2015 12:25:02 -0400 References: <1445576998-2921-1-git-send-email-eblake@redhat.com> <1445576998-2921-10-git-send-email-eblake@redhat.com> <87lhatbo1o.fsf@blackfin.pond.sub.org> <562A9C46.8010909@redhat.com> <87r3ki2iev.fsf@blackfin.pond.sub.org> From: Eric Blake Message-ID: <562E53D8.4050205@redhat.com> Date: Mon, 26 Oct 2015 10:24:56 -0600 MIME-Version: 1.0 In-Reply-To: <87r3ki2iev.fsf@blackfin.pond.sub.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="8onCOUi34B85GORRFnqhaS7SqPbgiB4fa" Subject: Re: [Qemu-devel] [PATCH v10 09/25] qapi: Prefer typesafe upcasts to qapi base classes List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: Gerd Hoffmann , Michael Roth , qemu-devel@nongnu.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --8onCOUi34B85GORRFnqhaS7SqPbgiB4fa Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 10/26/2015 01:33 AM, Markus Armbruster wrote: > Eric Blake writes: >=20 >> On 10/23/2015 09:30 AM, Markus Armbruster wrote: >>> Eric Blake writes: >>> >>>> A previous patch (commit 1e6c1616) made it possible to >>>> directly cast from a qapi type to its base type. A future >>>> patch will do likewise for structs. However, it requires >>>> the client code to use a C cast, which turns off compiler >>>> type-safety checks if the client gets it wrong. So this >>> >>> Who's the client? Suggest to simply drop "if the client gets it wron= g". >>> >>>> patch adds inline type-safe wrappers named qapi_FOO_base() >>>> for any type FOO that has a base, which can be used to >>>> upcast a qapi type to its base, then uses the new generated >>>> functions in places where we were already casting. >>>> >> >> Indeed, if I don't port gen_upcast() to types until patch 10/25, then >> this hunk also has to move to patch 10. That means no clients of the >> upcast macros in patch 9/25, _unless_ I add testsuite coverage. Which= I >> probably ought to do. >> >>>> switch (event) { >>>> case QAPI_EVENT_VNC_CONNECTED: >>>> - qapi_event_send_vnc_connected(si, vs->info->base, &error_ab= ort); >>>> + qapi_event_send_vnc_connected(si, qapi_VncClientInfo_base(v= s->info), >>>> + &error_abort); >>>> break; >>>> case QAPI_EVENT_VNC_INITIALIZED: >>>> qapi_event_send_vnc_initialized(si, vs->info, &error_abort)= ; >>> >>> Not a single cast to union base? >> >> Not that I could find. So I'll have to create one in the testsuite. >=20 > I guess I'd introduce gen_upcast() only with its first real user, > i.e. when unboxing struct base. At that time, its obvious > implementation should work for both struct and union, even though we > actually use it only for struct. If you want to add a test case for > unions, go ahead. I'm not sure I'd bother, because once we unify code > generation for the two, testing them separately won't add much value > anymore. It sounds like I have two options for v11: 1. Keep 9/25 introducing gen_upcast(), just for union types, and including testsuite coverage. In 10/25, make use of the upcast functions to struct as part of making structs sane. 2. Swap the patch order: do 10/25 to alter struct layout first, using ugly casts; then implement 9/25 that adds gen_upcast() and fixes the ugly casts to instead use the new upcast functions. I can go either way, so do you have any preference? --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --8onCOUi34B85GORRFnqhaS7SqPbgiB4fa 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/ iQEcBAEBCAAGBQJWLlPYAAoJEKeha0olJ0NqZQ4H/ing6gSTx2uB2bSXqTODI6Q3 lVmD0m4s6iiPpbZIREfCClG+hp1CseRvOKIlHem7elPGgxiQ59u3JFgx4itNWT0w kCZowUu6cV19NqORY2q+k8FuErsSC6Cq8zIq6CnJgPDV/uiWvFXKDkZumVBNkQ96 Ker3FnTZfrjEu3aOSqkgNP07FdKnNFFx4w1aXVT/yoemnPrJN6GCu4dlkbO8c1tB wUf8Jm6IqWALKeReJQdmjifdYCwFSl1k0ycrqLBS3E8UyDdOyrwFVxAOo6MjPNpF 381V59q7PIK+OvnE7F4ChDJQe1NVPfORfNO+ykk8VCB+SyB+aPNGkfihmJOd8gU= =2xEJ -----END PGP SIGNATURE----- --8onCOUi34B85GORRFnqhaS7SqPbgiB4fa--