[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v2 28/54] qapi: do not define enumeration value
From: |
Markus Armbruster |
Subject: |
Re: [Qemu-devel] [PATCH v2 28/54] qapi: do not define enumeration value explicitely |
Date: |
Wed, 06 Sep 2017 15:39:44 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) |
Marc-André Lureau <address@hidden> writes:
> ----- Original Message -----
>> Marc-André Lureau <address@hidden> writes:
>>
>> > The C standard has the initial value at 0 and the subsequent values
>> > incremented by 1. No need to set this explicitely.
>> >
>> > This will prevent from artificial "gaps" when compiling out some enum
>> > values and having unnecessarily large MAX values & enums arrays.
>>
>> Yes, but it also risks entertaining mishaps like compiling this one
>>
>> typedef enum Color {
>> COLOR_WHITE,
>> #if defined(NEED_CPU_H)
>> #if defined(TARGET_S390X)
>> COLOR_BLUE,
>> #endif /* defined(TARGET_S390X) */
>> #endif /* defined(NEED_CPU_H) */
>> COLOR_BLACK,
>> } Color;
>>
>> in s390x-code (COLOR_BLACK = 2) and in target-independent code
>> (COLOR_BLACK = 1), then linking the two together.
>
> This is also true with other kind of types, like struct.
>
> One of the main reason why we should have schemas for target-only and the
> NEED_CPU_H is a temporary working hack.
A temporary hack that's ugly or occasionally breaks in an obvious way is
okay, but this is an open deathtrap. I'm afraid we need to rethink our
short term conditional code generation strategy.
Stupidest solution that could possibly work: apply conditionals *only*
to qmp-introspect.c, leave everything unconditional elsewhere. What do
you think?