Eric Blake <ebl...@redhat.com> 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.
