From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45917) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zr5x3-0004lg-3v for qemu-devel@nongnu.org; Tue, 27 Oct 2015 11:14:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zr5wz-0004Dt-3O for qemu-devel@nongnu.org; Tue, 27 Oct 2015 11:14:17 -0400 Received: from mx1.redhat.com ([209.132.183.28]:42642) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zr5wy-0004Dk-Uc for qemu-devel@nongnu.org; Tue, 27 Oct 2015 11:14:13 -0400 From: Markus Armbruster References: <1445898903-12082-1-git-send-email-eblake@redhat.com> <1445898903-12082-24-git-send-email-eblake@redhat.com> <87mvv4iux6.fsf@blackfin.pond.sub.org> <562F88F8.4060508@redhat.com> Date: Tue, 27 Oct 2015 16:14:09 +0100 In-Reply-To: <562F88F8.4060508@redhat.com> (Eric Blake's message of "Tue, 27 Oct 2015 08:23:52 -0600") Message-ID: <87h9lc4a4e.fsf@blackfin.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Qemu-devel] [PATCH v11 23/24] qapi: Reserve 'u' member name List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: qemu-devel@nongnu.org, Michael Roth Eric Blake writes: > On 10/27/2015 02:21 AM, Markus Armbruster wrote: >> Eric Blake writes: >> >>> Now that we have separated union tag values from colliding with >>> non-variant C names, by naming the union 'u', we should reserve >>> this name for our use. Note that we want to forbid 'u' even in >>> a struct with no variants, because it is possible for a future >>> qemu release to extend QMP in a backwards-compatible manner while >>> converting from a struct to a flat union. Fortunately, no >>> existing clients were using this member name. If we ever find >>> the need for QMP to have a member 'u', we could at that time >>> relax things, perhaps by having c_name() munge the QMP member to >>> 'q_u'. >>> >>> Note that we cannot forbid 'u' everywhere (by adding the >>> rejection code to check_name()), because the existing QKeyCode >>> enum already uses it; therefore we only reserve it as a struct >>> type member name. >>> >>> Signed-off-by: Eric Blake >>> >>> --- >>> v11: commit message tweaks, use c_name(), tweak test names > >>> - if c_name(key).startswith('has_'): >>> + if c_name(key, False) == 'u' or c_name(key).startswith('has_'): >> >> Slightly odd: new c_name() has protect=False, the existing one doesn't. >> While we don't really need protect=False, it feels a bit cleaner. If >> you like, I can add it to the existing one when it gets added in PATCH >> 05. > > You're right - either both places need it, or neither place does. > Argument _for_ using c_name(, False): that's what we do in check_name() > when looking for 'q_', because we have to (if we use the default > c_name(, True), then the name gets munged and starts with q_ even though > the original did not). So even though we don't munge 'u' or 'has_' now, > if c_name() starts munging them in the future, consistently using > c_name(, False) here will protect us. So yes, make the change in patch 5. Done.