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. But in practice,
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.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org