From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55000) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZlthM-00020K-Sq for qemu-devel@nongnu.org; Tue, 13 Oct 2015 03:08:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZlthH-0006gW-UI for qemu-devel@nongnu.org; Tue, 13 Oct 2015 03:08:36 -0400 Received: from mx1.redhat.com ([209.132.183.28]:59377) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZlthH-0006gC-Q8 for qemu-devel@nongnu.org; Tue, 13 Oct 2015 03:08:31 -0400 From: Markus Armbruster References: <1443930073-19359-1-git-send-email-eblake@redhat.com> <1443930073-19359-12-git-send-email-eblake@redhat.com> <8737xgqe19.fsf@blackfin.pond.sub.org> <561BDE44.4000407@redhat.com> Date: Tue, 13 Oct 2015 09:08:27 +0200 In-Reply-To: <561BDE44.4000407@redhat.com> (Eric Blake's message of "Mon, 12 Oct 2015 10:22:28 -0600") Message-ID: <87fv1fgs9g.fsf@blackfin.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Qemu-devel] [PATCH v7 11/14] qapi: Move duplicate member checks to schema check() List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: Michael Roth , marcandre.lureau@redhat.com, qemu-devel@nongnu.org, ehabkost@redhat.com Eric Blake writes: > On 10/12/2015 09:53 AM, Markus Armbruster wrote: [...] >> It would be simpler if we could make C clash only when QMP clashes. > > If a QMP clash always caused a C clash, life would be a bit simpler. We > aren't going to get there (because in a flat union, hiding the members > of the branch type behind a single pointer means those members don't > clash with any C names of the overall union), but I can certainly try to > make the comments explain what is going on. (1) If QMP clashed exactly when C clashed, we'd have to think only about one of them, and the C compiler would check for clashes statically. (2) If a QMP clash implied a C clash, we'd only have to think about C, and the C compiler would check statically. (3) If a C clash implied a QMP clash, we'd only have to think about QMP. (4) If they can clash independently, we need to think about both independently. We currently have (4), and having to juggle both QMP and C in my mind has been taxing. My remark was about (3): C clashes only when QMP clashes <=> C clash implies QMP clash. Your remark was about (2). More useful than (3), but as you say not feasible. Do you think we can get to (3)? >> We might want to separate out alternates. Dunno. > > And to some extent, subset C already does some of that separation > (because I try to convert from 'FooKind type' to 'qtype_code type' > without even creating an implicit 'FooKind' enum). It sounds like > you're okay with any well-documented TODO warts related to alternates > for the purposes of this subset B, especially if I can then clean those > warts back up in subset C. But what v8 of subset B needs to avoid is > any warts based on simple vs. flat unions. I can live with that. I'm prepared to accept rephrased existing warts and additional temporary warts when I understand why simply fixing them isn't practical or economical. A certain amount of hand-waving is okay. > I'm still trying to figure out if hoisting the kind=>type rename into > subset B makes life easier or harder (it certainly causes me more rebase > churn, but that's not necessarily a bad thing). Thanks!