From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:46600)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1XRjtR-0001mq-Lg
	for qemu-devel@nongnu.org; Wed, 10 Sep 2014 11:33:19 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1XRjtL-00047Q-IP
	for qemu-devel@nongnu.org; Wed, 10 Sep 2014 11:33:13 -0400
Received: from mx1.redhat.com ([209.132.183.28]:24258)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1XRjtL-00047C-Bh
	for qemu-devel@nongnu.org; Wed, 10 Sep 2014 11:33:07 -0400
Message-ID: <54106F28.5080203@redhat.com>
Date: Wed, 10 Sep 2014 17:32:56 +0200
From: Paolo Bonzini <pbonzini@redhat.com>
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>
In-Reply-To: <20140910150200.GA4883@fam-t430.nay.redhat.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH] qapi: Fix crash with enum dealloc when
	kind is invalid
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Fam Zheng <famz@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>, qemu-devel@nongnu.org, Michael Roth <mdroth@linux.vnet.ibm.com>, Markus Armbruster <armbru@redhat.com>, Stefan Hajnoczi <stefanha@redhat.com>, Luiz Capitulino <lcapitulino@redhat.com>

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 enum"
> > value?  The dealloc visitor could override it to do nothing, while the
> > 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.

Paolo