Re: [Qemu-devel] [PATCH RFC v2 27/47] qapi-visit: Convert to QAPISchemaVisitor, fixing bugs

[Markus Armbruster]

Eric Blake <address@hidden> writes:

> On 07/28/2015 12:41 AM, Markus Armbruster wrote:
>>> Like reserving ourselves a namespace based on single _ for internal use.
>>>  We practically already have that - all user names either start with a
>>> letter or double underscore, so we could use single (and triple)
>>> underscore for internally-generated purposes, freeing up 'base',
>>> '*Kind', '*_MAX', and other namespace abuses back to the user.  Well, we
>>> may also need to reserve mid-name double-underscore (that is, the user
>>> can only supply double underscore at the beginning, but not middle, of
>>> an identifier).  Ah well, food for thought for later patches.
>> 
>> Another concern: we should take care not to generate reserved
>> identifiers.
>
> And we do that for a number of identifiers already, by renaming
> 'default' in qapi to 'q_default' in C.
>
>> 
>> * Potential issue with your proposal: identifiers that begin with an
>>   underscore and either an uppercase letter or another underscore are
>>   always reserved for any use.
>
> True, so only underscore and lower is guaranteed safe.

And we'd get that for most names.  Only names we want to shout (macros,
enumeration constants) could result in a problematic underscore and
uppercase letter.

Note that we *strip* leading underscores from enumeration constants.
Example (from qapi-schema-test.json):

    { 'enum': '__org.qemu_x-Enum', 'data': [ '__org.qemu_x-value' ] }

generates

    typedef enum __org_qemu_x_Enum
    {
        ORG_QEMU_X_ENUM___ORG_QEMU_X_VALUE = 0,
        ORG_QEMU_X_ENUM_MAX = 1,
    } __org_qemu_x_Enum;

Now add this one:

    { 'enum': 'org_qemu_x-Enum', 'data': [ ] }

Just fine according to our documentation.  But of course it clashes:

    typedef enum org_qemu_x_Enum
    {
        ORG_QEMU_X_ENUM_MAX = 0,
    } org_qemu_x_Enum;

Short term, we should note in qapi-code-gen.txt: different names in the
schema can nevertheless clash in generated C, and when that happens, you
get to pick non-clashing names.

Longer term, we may want to rethink how we map names to C.

> we can often get away with more...
>
>> 
>> * Existing issue: downstream extensions carry a __RFQDN_ prefix in the
>>   schema, which map to reserved C identifiers.
>
> ...the whole point of the __RFQDN_ prefix was that it is very unlikely
> to conflict with any vendor extensions (unless you happen to be the same
> vendor that writes the compiler and als use __RFQDN_ as part of your
> compiler implementation).  Yes, it's risky, but a risk that hasn't hurt
> any downstream clients yet :)  It's one of those things where if someone
> reports an actual problem in their environment, we'll fix it; but until
> then, it's not worth the headache of strict compliance to "fix"
> something that happens to work in spite of being undefined behavior.

I'm not religious about reserved names, but this intrusion into the
reserved name space was entirely avoidable: we could've just as well
picked a non-reserved prefix.