From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40746) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ysjz6-0002S3-Pl for qemu-devel@nongnu.org; Wed, 13 May 2015 23:38:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ysjz2-0002nz-Hd for qemu-devel@nongnu.org; Wed, 13 May 2015 23:38:56 -0400 Received: from mx1.redhat.com ([209.132.183.28]:50080) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ysjz2-0002nK-Ao for qemu-devel@nongnu.org; Wed, 13 May 2015 23:38:52 -0400 Message-ID: <55541899.1030804@redhat.com> Date: Wed, 13 May 2015 21:38:01 -0600 From: Eric Blake MIME-Version: 1.0 References: <1430829055-4739-1-git-send-email-eblake@redhat.com> <1430829055-4739-9-git-send-email-eblake@redhat.com> <877fskbzub.fsf@blackfin.pond.sub.org> In-Reply-To: <877fskbzub.fsf@blackfin.pond.sub.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="DCtWh1IAV1WNoO8i2l2lEJ2VAQsoafKdi" Subject: Re: [Qemu-devel] [PATCH v3 08/14] qapi: Make c_type() consistently convert qapi names List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: kwolf@redhat.com, akong@redhat.com, berto@igalia.com, qemu-devel@nongnu.org, mdroth@linux.vnet.ibm.com This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --DCtWh1IAV1WNoO8i2l2lEJ2VAQsoafKdi Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 05/07/2015 01:39 AM, Markus Armbruster wrote: > Eric Blake writes: >=20 >> Continuing the string of cleanups for supporting downstream names >> containing '.', this patch focuses on ensuring c_type() can >> handle a downstream name. This patch alone does not fix the >> places where generator output should be calling this function >> but was open-coding things instead, but it gets us a step closer. >> >> Note that we generate a List type for our builtins; the code has >> to make sure that ['int'] maps to 'intList' (and not 'q_intList'), >> and that a member with type 'int' still maps to the C type 'int'; >> on the other hand, a member with a name of 'int' will still map >> to 'q_int' when going through c_name(). This patch had to teach >=20 > has to teach >=20 >> type_name() to special-case builtins, since it is used by >> c_list_type() which in turn feeds c_type(). >> >> >> +# This function is used for converting the type of 'member':'name' in= to a >> +# substring for use in C pointer types or function names. >=20 > Likewise: >=20 > # Map type @name to its C typedef name. > # >=20 > Consider rename parameter @name, because it can either be a name string= , > or a list containing a name string. Same for the other functions. > Perhaps in a separate patch for easier review. Sure, will split out a second patch, and post v4 shortly. c_name() only operates on strings, but type_name() and c_type() do indeed operate on more than just strings. >=20 >> def type_name(name): >> if type(name) =3D=3D list: >> return c_list_type(name[0]) >> - return name >> + if name in builtin_types.keys(): >> + return name >> + return c_name(name) >=20 > Together with the change to c_list_type(), this changes type_name() as > follows: >=20 > * Name FOO becomes c_name(FOO) instead of FOO, except when FOO is the > name of a built-in type. Bug fix when FOO contains '.' or '-' or is > a ticklish identifier other than a built-in type. >=20 > * List of FOO becomes c_name(FOO) + "List" instead of FOOList. Bug fix= > when FOO contains '.' or '-'. Not a bug fix when ticklish FOO become= s > q_FOO, but improves consistency with the element type's C name then. >=20 > Correct? Yes. 'unix'->"q_unix" but ['unix']->"unixList" was inconsistent, so it is now "q_unixList". But ['int'] must map to "intList" and not "q_intList", because we have implementations for intList but do not need generated code for the builtin type int. >=20 > # Map type @name to its C type expression. > # If @is_param, const-qualify the string type. > # > # A special suffix... >=20 >> @@ -888,13 +897,13 @@ def c_type(name, is_param=3DFalse): >> elif type(name) =3D=3D list: >> return '%s *%s' % (c_list_type(name[0]), eatspace) >> elif is_enum(name): >> - return name >> + return c_name(name) >> elif name =3D=3D None or len(name) =3D=3D 0: >> return 'void' >=20 > Aside: len(name) =3D=3D 0 is a lame way to test name =3D=3D "". > Aside^2: I wonder whether we ever pass that. I'll find out :) >=20 >> elif name in events: >> return '%sEvent *%s' % (camel_case(name), eatspace) >> else: >> - return '%s *%s' % (name, eatspace) >> + return '%s *%s' % (c_name(name), eatspace) >=20 > I figure the else is for complex types. If that's correct, we should > perhaps add a comment. Yes, at this point, all that is left is complex types. >=20 >> >> def is_c_ptr(name): >> suffix =3D "*" + eatspace >=20 > Together with the change to c_list_type(), this changes c_type() as > follows: >=20 > * Enum FOO becomes c_name(FOO) instead of FOO. Bug fix when FOO > contains '.' or '-' or is a ticklish identifier. >=20 > * Complex type FOO becomes c_name(FOO) + "*" instead of FOO *. Bug fix= > when FOO contains '.' or '-' or is a ticklish identifier. >=20 > * List of FOO becomes c_name(FOO) + "List *" instead of FOOList *. Bug= > fix when FOO contains '.' or '-'. Not a bug fix when ticklish FOO > becomes q_FOO, but improves consistency with the element type's C nam= e > then. >=20 > Correct? Yes. I can try and fold that into the commit message. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --DCtWh1IAV1WNoO8i2l2lEJ2VAQsoafKdi 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/ iQEcBAEBCAAGBQJVVBiZAAoJEKeha0olJ0NqlmIH/3O2XOKnRkmYg+Sjw3AbdPmQ U/VmdPGUZG6SAiwyvK/pSx6Ssy2qCUKzcNl5/gN2VGaxYUFrDr4q4u33QHkWomgS 2jQdEfrNzVFQLBMk89RH/orSnwg7vLxrpQtORhyLTRmApQVVNp1hc4Kx30e8x/YK 5ceChNMW7WcdE8DKY7GbGSufw9HnYqOWWDiFA0HbjY8gXLF6gJvRbftgx9ldPoHD xui8OTwuRNlLkZFawqYHscmbmuAWUy8kpOo+2qr1TaHoT3PFzsnTgfx7NV/Akx0b rOxkrYoBBTUCcgKGvBoAHODOeZa2RaQEgIUsll3eD40yyseg+jfhDDvzhEDUW2c= =lG40 -----END PGP SIGNATURE----- --DCtWh1IAV1WNoO8i2l2lEJ2VAQsoafKdi--