From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41457) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZzSpR-0002i9-LP for qemu-devel@nongnu.org; Thu, 19 Nov 2015 12:17:03 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZzSpN-00024U-49 for qemu-devel@nongnu.org; Thu, 19 Nov 2015 12:17:01 -0500 Received: from mx1.redhat.com ([209.132.183.28]:34817) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZzSpM-00024O-SE for qemu-devel@nongnu.org; Thu, 19 Nov 2015 12:16:57 -0500 References: <1447836791-369-1-git-send-email-eblake@redhat.com> <1447836791-369-28-git-send-email-eblake@redhat.com> <8737w23pcr.fsf@blackfin.pond.sub.org> From: Eric Blake Message-ID: <564E0403.5030602@redhat.com> Date: Thu, 19 Nov 2015 10:16:51 -0700 MIME-Version: 1.0 In-Reply-To: <8737w23pcr.fsf@blackfin.pond.sub.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="tdWhdpK8hXImIKu06s4CqWh18QC7x7hk0" Subject: Re: [Qemu-devel] [PATCH v12 27/36] qapi: Forbid case-insensitive clashes List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: qemu-devel@nongnu.org, Michael Roth This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --tdWhdpK8hXImIKu06s4CqWh18QC7x7hk0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 11/19/2015 09:50 AM, Markus Armbruster wrote: > Let's think through this on a higher level. >=20 > I figure the motivation for this patch is twofold: >=20 > 1. C identifier clash detection >=20 >=20 > 2. Dislike for interfaces that differ only in case And the related dislike for interfaces that differ only in '-' or '_'. > Our naming conventions actually make clashes due to folding relatively > unlikely. They are: >=20 > * All names consist of letters, digits, '-' and '_', starting with a > letter. >=20 > * Event names are ALL_CAPS, i.e. they use neither lower case nor '-'. >=20 > Without lower case, '-' and '.', clash due to folding is impossible. So if we enforce that convention, we don't have to worry about case clash, and I don't think we have any outliers to whitelist. >=20 > * Command names, member names and built-in type names are dashed-lower,= > i.e. they use neither upper case nor '_'. >=20 > Without upper case, '_', and '.', clash due to folding is impossible.= If we enforce that convention, we have to whitelist outliers (for example, 'netdev_add' as a command name, or a number of types whose members still use '_'). The existence of a whitelist will discourage future clashes, without any of the hassle of coding up clash checks. >=20 > * Type names are CamelCase. They do not use '_' or '-'. >=20 > Can theoretically clash in amusing ways: ONegus, OneGus. > Ain'tCamelCaseFun! Do we have any outliers? >=20 > We can get rid of the clashes by not case folding type names. See > "[PATCH RFC 3/5] qapi: Use common name mangling for enumeration > constants". The patch additionally drops folding of enumeration > member names, which isn't necessary. Controversial. There is even the possibility of mixed treatment (enumeration name portion as-is, member name portion shouted, as in 'MyTypeVALUE1'). Not sure if we'll get a clear answer to the controversy, but also not sure it is worth holding up other patches while discussing that. >=20 > * Additionally, any name may be prefixed by __RFQDN_. RFQDN consists o= f > letters, digits '-' and '.'. >=20 > Because unprefixed names start with a letter, and the prefix starts > with '__', prefixed names cannot clash with unprefixed names. >=20 > If we additionally stipulated that event prefixes are upper case, and= > all others lower case, prefixes couldn't contribute to clashes at all= =2E It's a bit weird that we'd have __org.qemu_command and __ORG.QEMU_EVENT for the same vendor. On the other hand, FQDN is already case-insensitive (qemu.org and QEMU.ORG resolve to the same address). So there won't be clashes between vendors (as no two vendors can share a FQDN that differs in case); beyond that, if a vendor wants to play weird case games, that's their (downstream) problem, not ours. >=20 > Strict adherence to our naming conventions would eliminate clashes due > to folding except for type names. A single extra dictionary mapping > c_name(typ.name).lower() to typ would suffice. Certainly may be simpler than carrying three dictionaries for command/event/type. >=20 > What happens to the rest of your queue if we shelve this patch for now?= Not much; in fact, according to the patch version log: --- v12: add in entity case collisions (required sharing two maps), improve commit message v11: rebase to latest, don't focus so hard on future case-insensitive extensions, adjust commit message v10: new patch --- I only even added it due to conversations on v9, and intentionally kept it separate from 'qapi: Detect collisions in C member names' (we absolutely want to report exact-name collisions, whether or not we also decide to report case collisions). It should not be a problem to defer this patch (or a better version of it that enforces conventions, adds whitelist handling, then only worries about type name case collisions) to much later, if at all. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --tdWhdpK8hXImIKu06s4CqWh18QC7x7hk0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJWTgQDAAoJEKeha0olJ0Nq4gsIAJQbeK5vUV/G/dESOSVGFbgz 5DNPMlc9BaEyAXLsx6egQ3D0SNL/a+vwy/NgfmeCHPmsoEql4x5jWLQWnH7LUxYB Nn1T3B9xkONl17twol1PXZNwk6PVByyPwwBvzncI9PKJCgHI4uR/AVNxm43zQLDv BfM59Ukj/47MDD1z9+1iXA0h4qLfL0Nqe7mRFfVs2fW3p14+YjiWMMh7HbgzQP5X 5a62xzTZIDuCOI+XSviZ4Ca1uCvfpy5GqgV9IYwPRI1mnVQWpEuNnO46o6TLziuJ 8kXTdjOxftL6Huk4ZCHp7dqrIcMZxzS5TtLO8vuUbNlzGftiAT19XJIlDuxFdvw= =Xv3S -----END PGP SIGNATURE----- --tdWhdpK8hXImIKu06s4CqWh18QC7x7hk0--