Re: [Qemu-devel] [PATCH v8 10/17] qapi: Simplify visiting of alternate types

[Markus Armbruster]

Eric Blake <address@hidden> writes:

> On 11/04/2015 09:03 AM, Markus Armbruster wrote:
>
>> Conclusions:
>> 
>> * Having two different name manglers is a headache we could do without,
>>   especially since the second one camel_to_upper() is pretty magic.
>> 
>>   We have it only to get
>> 
>>     typedef enum BlockDeviceIoStatus {
>>         BLOCK_DEVICE_IO_STATUS_OK = 0,
>>         BLOCK_DEVICE_IO_STATUS_FAILED = 1,
>>         BLOCK_DEVICE_IO_STATUS_NOSPACE = 2,
>>         BLOCK_DEVICE_IO_STATUS_MAX = 3,
>>     } BlockDeviceIoStatus;
>> 
>>   instead of
>> 
>>     typedef enum BlockDeviceIoStatus {
>>         BlockDeviceIoStatus_ok = 0,
>>         BlockDeviceIoStatus_failed = 1,
>>         BlockDeviceIoStatus_nospace = 2,
>>         BlockDeviceIoStatus_MAX = 3,
>>     } BlockDeviceIoStatus;
>> 
>>   Bah!  CODING_STYLE doesn't even ask for shouting enumeration
>>   constants.  Can't see why we do.
>
> Interesting idea.  In fact, if we went one step further:
>
> BlockDeviceIoStatus_ok = 0,
> ...
> BlockDeviceIoStatusMAX = 3.
>
> (that is, typename + '_' + value for user values, and typename + 'MAX'
> for the sentinel), then the max value _cannot_ collide with any of the
> other values.

Another arbitrary rule killed.

>> * Keeping the complexity of the rules under control is good both for
>>   qapi.py and for the QAPI schema language.
>> 
>>   To that end, I think we should consider reserving the same set of
>>   names both for members and tag values.  It gets rid of complications
>>   like enumerations you can't use as flat union tags.
>> 
>>   Additionally, the question whether to keep the door open for
>>   generating an enum for the alternate cases becomes moot.
>> 
>> What do you think?
>
> I like the idea. Don't know if it's too late for 2.5, though.

The only risk with renaming obviously unique identifiers is producing
merge conflicts.  Annoying, but easy enough to resolve.

How much churn exactly?  I count 1423 occurences of generated
enumeration constants in 143 out of 4442 source files.  Top-scorer is of
course QKeyCode, with 471 occurences in 9 files, almost all in tables.
I've seen worse.  I wouldn't ask for such a pull during hard freeze, of
course.  During soft freeze, merge conflict risk might be lower than
usual.