From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48749) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XRvoz-0000k9-Ui for qemu-devel@nongnu.org; Thu, 11 Sep 2014 00:17:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XRvos-0006wz-0w for qemu-devel@nongnu.org; Thu, 11 Sep 2014 00:17:25 -0400 Received: from mx1.redhat.com ([209.132.183.28]:27898) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XRvor-0006ws-PC for qemu-devel@nongnu.org; Thu, 11 Sep 2014 00:17:17 -0400 Message-ID: <54112247.40303@redhat.com> Date: Wed, 10 Sep 2014 22:17:11 -0600 From: Eric Blake MIME-Version: 1.0 References: <1410352239-8705-1-git-send-email-famz@redhat.com> <54104BA9.4040308@redhat.com> <20140910150200.GA4883@fam-t430.nay.redhat.com> <54106F28.5080203@redhat.com> <20140911005328.GB2554@fam-t430.nay.redhat.com> In-Reply-To: <20140911005328.GB2554@fam-t430.nay.redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="UM38sUDvTqE8dxW4es4gVebF9EEmqAmqw" Subject: Re: [Qemu-devel] [PATCH] qapi: Fix crash with enum dealloc when kind is invalid List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Fam Zheng , Paolo Bonzini Cc: Kevin Wolf , qemu-devel@nongnu.org, Hu Tao , Michael Roth , Markus Armbruster , Stefan Hajnoczi , Luiz Capitulino This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --UM38sUDvTqE8dxW4es4gVebF9EEmqAmqw Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 09/10/2014 06:53 PM, Fam Zheng wrote: > On Wed, 09/10 17:32, Paolo Bonzini wrote: >> Il 10/09/2014 17:02, Fam Zheng ha scritto: >>>> A bit hackish, but I don't have any better idea. >>>> >>>> Hmm... what about adding a new member to the visitors for "invalid e= num" >>>> value? The dealloc visitor could override it to do nothing, while t= he >>>> default could abort or set an error. Would that work? >>> >>> The invalid state of enum still needs to be saved in the data. It is= detected >>> by the input visitor, but should be checked by other visitors (output= , dealloc) >>> later. >> >> Yes, that's fine. The only part where I'm not sure is the special >> casing of the _MAX enum. >> >=20 > Yes, it is abusing. Let's add an _INVALID =3D 0 enum which is much clea= rer. If I understand correctly, you mean that for: { 'enum': 'Foo', 'data': [ 'one', 'two' ] } FOO_ONE would now be 1 instead of its current value of 0? We just barely saw a case where Hu Tao's code was relying on the implicit value 0 assigned to the first enum in the json file [1] although I strongly argued that it should be nuked (and so it was fixed in [2]). So I could live with reserving 0 for internal use for flagging parse errors (such as attempting to pass the string 'three' where a Foo value is expected). [1] https://lists.gnu.org/archive/html/qemu-devel/2014-09/msg01691.html [2] https://lists.gnu.org/archive/html/qemu-devel/2014-09/msg01938.html --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --UM38sUDvTqE8dxW4es4gVebF9EEmqAmqw Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg iQEcBAEBCAAGBQJUESJHAAoJEKeha0olJ0NqN1cH/RRQkai5xTYObyFYihB2RmFx C5ibuezkbdQQszHMQ2fK+VeoBqXZya50aSryWYlQHpOgZKjr67YJi8WpfArKCPQW /kkBgifygYf+67q06ntqZFXV6jWa8GkOiZmRNtAA2Ofa96eN/zgUQW9S9GUmwh5G 3kPoSfiIqxkCQliVS3+rHnJPTS6hLgYoKWXtvlyrE7HRRbuFPELCA1iSaE2oNzfH wnEq5zPGZRc+aE9zE/zde9kPQVsn1zFpP0TkOeNozKuAJmNcyK62sp/lhfTDCv1d bjueKym5do7Pxh4K1jGEUVtZzqmFg2c/A8jc6XxBEPHh+rcyY3hSc1/8PgTfvS8= =nud2 -----END PGP SIGNATURE----- --UM38sUDvTqE8dxW4es4gVebF9EEmqAmqw--