From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50561) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XSTji-0005l6-M0 for qemu-devel@nongnu.org; Fri, 12 Sep 2014 12:30:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XSTjb-0004li-Sw for qemu-devel@nongnu.org; Fri, 12 Sep 2014 12:30:14 -0400 Sender: Paolo Bonzini Message-ID: <54131F7A.3000809@redhat.com> Date: Fri, 12 Sep 2014 18:29:46 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1410477659-9163-1-git-send-email-mdroth@linux.vnet.ibm.com> <1410477659-9163-2-git-send-email-mdroth@linux.vnet.ibm.com> <5412C828.2070004@redhat.com> <20140912153447.19243.81596@loki> <541313C5.40103@redhat.com> <20140912161720.19243.93082@loki> In-Reply-To: <20140912161720.19243.93082@loki> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 1/3] qapi: add visit_start_union and visit_end_union List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Michael Roth , qemu-devel@nongnu.org Cc: armbru@redhat.com, famz@redhat.com, qemu-stable@nongnu.org, lcapitulino@redhat.com Il 12/09/2014 18:17, Michael Roth ha scritto: > Quoting Paolo Bonzini (2014-09-12 10:39:49) >> Il 12/09/2014 17:34, Michael Roth ha scritto: >>> >>> { 'union': 'UserDefUnion', >>> 'base': 'UserDefZero', >>> 'data': { 'a' : 'int', 'b' : 'UserDefB' } } >>> >>> If UserDefUnion.a is 0, UserDefUnion.data will cast it to a NULL value and >>> cause the output visitor to bail, when really it should just be left to >>> continue on serializing the integer. >> >> In the case of dealloc, that'd be okay because the dealloc visit would >> do nothing for KIND_A, right? > > Yup that should be fine for the dealloc visitor. With this series we never > actually visit the int in this case though due to this quirk. But that's > okay because it's not an allocated type and the dealloc visitor doesn't need > to do anything anyway. (It's a bit wonky, but since that reliance on > implementation details now lives in the visitor implementation of > visit_start_union it's reasonably contained at least) > > But if we're looking at extending visit_start_union for use in something like > an output visitor, this would need to be addressed some other way, since > skipping scalar fields because they're 0 is a bug there. I guess it would be something like has_data = (kind < KIND_MAX) && (is_scalar[kind] || !!data) That could be done in qapi-visit.py if we were so inclined... Paolo