[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH RFC v2 27/47] qapi-visit: Convert to QAPISchemaV

From: Eric Blake
Subject: Re: [Qemu-devel] [PATCH RFC v2 27/47] qapi-visit: Convert to QAPISchemaVisitor, fixing bugs
Date: Tue, 28 Jul 2015 08:46:33 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0

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

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]