From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38919) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZwWmV-0000US-0c for qemu-devel@nongnu.org; Wed, 11 Nov 2015 09:53:55 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZwWmR-0004sP-Ra for qemu-devel@nongnu.org; Wed, 11 Nov 2015 09:53:50 -0500 Received: from mx1.redhat.com ([209.132.183.28]:41494) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZwWmR-0004sJ-M9 for qemu-devel@nongnu.org; Wed, 11 Nov 2015 09:53:47 -0500 From: Markus Armbruster References: <1447224690-9743-1-git-send-email-eblake@redhat.com> <1447224690-9743-21-git-send-email-eblake@redhat.com> Date: Wed, 11 Nov 2015 15:53:40 +0100 In-Reply-To: <1447224690-9743-21-git-send-email-eblake@redhat.com> (Eric Blake's message of "Tue, 10 Nov 2015 23:51:22 -0700") Message-ID: <878u64bn9n.fsf@blackfin.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Qemu-devel] [PATCH v11 20/28] qapi: Forbid case-insensitive clashes 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: > In general, designing user interfaces that rely on case > distinction is poor practice. Another benefit of enforcing > a restriction against case-insensitive clashes is that we > no longer have to worry about the situation of enum values > that could be distinguished by case if mapped by c_name(), > but which cannot be distinguished when mapped to C as > ALL_CAPS by camel_to_upper(). With PATCH 19, they're mapped by c_name(N).upper(). > Thus, having the generator > look for case collisions up front will prevent developers > from worrying whether different munging rules for member > names compared to enum values as a discriminator will cause > any problems in qapi unions. > > There is also the possibility that we may want to add a > future extension to QMP of teaching it to be case-insensitive > (the user could request command 'Quit' instead of 'quit', or > could spell a struct field as 'CPU' instead of 'cpu'). But > for that to be a practical extension, we cannot break > backwards compatibility with any existing struct that was > already relying on case sensitivity. Fortunately, after the > previous patch cleaned up CpuInfo, there are no such existing > qapi structs. Of course, the idea of a future extension is > not as strong of a reason to make the change. > > At any rate, it is easier to be strict now, and relax things > later if we find a reason to need case-sensitive QMP members, > than it would be to wish we had the restriction in place. Suggest to briefly mention the new test. > Signed-off-by: Eric Blake Patch looks good.