From: Eric Blake <eblake@redhat.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: kwolf@redhat.com, akong@redhat.com, berto@igalia.com,
qemu-devel@nongnu.org, mdroth@linux.vnet.ibm.com
Subject: Re: [Qemu-devel] [PATCH v3 08/14] qapi: Make c_type() consistently convert qapi names
Date: Wed, 13 May 2015 21:38:01 -0600 [thread overview]
Message-ID: <55541899.1030804@redhat.com> (raw)
In-Reply-To: <877fskbzub.fsf@blackfin.pond.sub.org>
[-- Attachment #1: Type: text/plain, Size: 4421 bytes --]
On 05/07/2015 01:39 AM, Markus Armbruster wrote:
> Eric Blake <eblake@redhat.com> writes:
>
>> 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
>
> has to teach
>
>> 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' into a
>> +# substring for use in C pointer types or function names.
>
> Likewise:
>
> # Map type @name to its C typedef name.
> # <Explanation of intended use goes here>
>
> 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.
>
>> def type_name(name):
>> if type(name) == list:
>> return c_list_type(name[0])
>> - return name
>> + if name in builtin_types.keys():
>> + return name
>> + return c_name(name)
>
> Together with the change to c_list_type(), this changes type_name() as
> follows:
>
> * 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.
>
> * 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 name then.
>
> 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.
>
> # Map type @name to its C type expression.
> # If @is_param, const-qualify the string type.
> # <Explanation of intended use goes here>
> # A special suffix...
>
>> @@ -888,13 +897,13 @@ def c_type(name, is_param=False):
>> elif type(name) == list:
>> return '%s *%s' % (c_list_type(name[0]), eatspace)
>> elif is_enum(name):
>> - return name
>> + return c_name(name)
>> elif name == None or len(name) == 0:
>> return 'void'
>
> Aside: len(name) == 0 is a lame way to test name == "".
> Aside^2: I wonder whether we ever pass that.
I'll find out :)
>
>> elif name in events:
>> return '%sEvent *%s' % (camel_case(name), eatspace)
>> else:
>> - return '%s *%s' % (name, eatspace)
>> + return '%s *%s' % (c_name(name), eatspace)
>
> 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.
>
>>
>> def is_c_ptr(name):
>> suffix = "*" + eatspace
>
> Together with the change to c_list_type(), this changes c_type() as
> follows:
>
> * Enum FOO becomes c_name(FOO) instead of FOO. Bug fix when FOO
> contains '.' or '-' or is a ticklish identifier.
>
> * Complex type FOO becomes c_name(FOO) + "*" instead of FOO *. Bug fix
> when FOO contains '.' or '-' or is a ticklish identifier.
>
> * 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 name
> then.
>
> Correct?
Yes. I can try and fold that into the commit message.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]
next prev parent reply other threads:[~2015-05-14 3:38 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-05 12:30 [Qemu-devel] [PATCH v3 00/14] Fix qapi mangling of downstream names Eric Blake
2015-05-05 12:30 ` [Qemu-devel] [PATCH v3 01/14] qapi: Fix C identifiers generated for names containing '.' Eric Blake
2015-05-05 12:30 ` [Qemu-devel] [PATCH v3 02/14] qapi: Rename identical c_fun()/c_var() into c_name() Eric Blake
2015-05-07 7:39 ` Markus Armbruster
2015-05-05 12:30 ` [Qemu-devel] [PATCH v3 03/14] qapi: Rename _generate_enum_string() to camel_to_upper() Eric Blake
2015-05-05 12:30 ` [Qemu-devel] [PATCH v3 04/14] qapi: Rename generate_enum_full_value() to c_enum_const() Eric Blake
2015-05-05 12:30 ` [Qemu-devel] [PATCH v3 05/14] qapi: Simplify c_enum_const() Eric Blake
2015-05-05 12:30 ` [Qemu-devel] [PATCH v3 06/14] qapi: Use c_enum_const() in generate_alternate_qtypes() Eric Blake
2015-05-05 12:30 ` [Qemu-devel] [PATCH v3 07/14] qapi: Move camel_to_upper(), c_enum_const() to closely related code Eric Blake
2015-05-05 12:30 ` [Qemu-devel] [PATCH v3 08/14] qapi: Make c_type() consistently convert qapi names Eric Blake
2015-05-07 7:39 ` Markus Armbruster
2015-05-14 3:38 ` Eric Blake [this message]
2015-05-05 12:30 ` [Qemu-devel] [PATCH v3 09/14] qapi: Support downstream enums Eric Blake
2015-05-07 7:47 ` Markus Armbruster
2015-05-05 12:30 ` [Qemu-devel] [PATCH v3 10/14] qapi: Support downstream structs Eric Blake
2015-05-07 7:48 ` Markus Armbruster
2015-05-05 12:30 ` [Qemu-devel] [PATCH v3 11/14] qapi: Support downstream simple unions Eric Blake
2015-05-07 7:49 ` Markus Armbruster
2015-05-05 12:30 ` [Qemu-devel] [PATCH v3 12/14] qapi: Support downstream flat unions Eric Blake
2015-05-07 7:49 ` Markus Armbruster
2015-05-05 12:30 ` [Qemu-devel] [PATCH v3 13/14] qapi: Support downstream alternates Eric Blake
2015-05-07 7:50 ` Markus Armbruster
2015-05-05 12:30 ` [Qemu-devel] [PATCH v3 14/14] qapi: Support downstream events and commands Eric Blake
2015-05-07 7:53 ` Markus Armbruster
2015-05-12 15:37 ` [Qemu-devel] [PATCH v3 00/14] Fix qapi mangling of downstream names Markus Armbruster
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55541899.1030804@redhat.com \
--to=eblake@redhat.com \
--cc=akong@redhat.com \
--cc=armbru@redhat.com \
--cc=berto@igalia.com \
--cc=kwolf@redhat.com \
--cc=mdroth@linux.vnet.ibm.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).