On 8/23/2026 11:01 PM, Markus Armbruster wrote:
> Pierrick Bouvier <[email protected]> writes:
>
>> With the single-binary, we start mixing types for different targets,
>> that may or may not be available for current one.
>>
>> Previously, we implemented an approach based on interfaces, but it
>> proved to be too limited. It requires duplication between
>> machines/cpus/devices, and does not handle specific cases where a type
>> should be available based on a target configuration (Kconfig).
>>
>> To solve this, we add a new field, available_if, to TypeInfo.
>> It is an array containing a list of requirements for type to be
>> available.
>>
>> For now, we have only targets as requirements, but later we'll add
>> specific target config entries also.
>>
>> We also add a TARGET_REQS macro, to declare a list of requirements. For
>> sanity sake, we don't use a complex variadic macro prefixing each
>> parameter. It requires a lot of macro boilerplate in C, and prevent
>> readers to jump easily to definition for each parameter.
>>
>> Signed-off-by: Pierrick Bouvier <[email protected]>
>> ---
>> include/qemu/target-info.h | 11 +++++++++++
>> include/qom/object.h | 5 +++++
>> qom/object.c | 10 ++++++++++
>> rust/qom/src/qom.rs | 1 +
>> stubs/meson.build | 1 +
>> stubs/target-info.c | 11 +++++++++++
>> target-info.c | 13 +++++++++++++
>> 7 files changed, 52 insertions(+)
>> create mode 100644 stubs/target-info.c
>>
>> diff --git a/include/qemu/target-info.h b/include/qemu/target-info.h
>> index 6c5b714288e..6379e65bbcf 100644
>> --- a/include/qemu/target-info.h
>> +++ b/include/qemu/target-info.h
>> @@ -50,6 +50,17 @@ const char *target_cpu_type(void);
>> */
>> bool target_big_endian(void);
>>
>> +typedef enum TargetReq {
>> + /* 0 is reserved for end of array */
>> + TARGET_REQ_BASE_ARM = 1,
>> + TARGET_REQ_AARCH64,
>> + TARGET_REQ_ARM,
>> +} TargetReq;
>> +
>> +#define TARGET_REQS(...) (const TargetReq[]){__VA_ARGS__, 0}
>
> The sentinel 0 is not a member of the enum.
>
> Is this safe? I'm asking because the C standard is infatuated with
> undefined behavior. Checking C99... all I can find is Annex I "Common
> warnings"
>
> -- A value is given to an object of an enumeration type
> other than by assignment of an enumeration constant
> that is a member of that type, or an enumeration
> variable that has the same type, or the value of a
> function that returns the same enumeration type
>
> Looks like it's safe.
>
As far as I know, it's safe as long as the value you set can be hold in
underlying type (in C or C++) chosen by compiler. Obviously, 0 is a safe
choice for any storage type.
That's also why the compiler will warn you a function having this
pattern misses a return value:
typedef enum {
A,
B,
} Enum
int f(Enum myEnum) {
switch(myEnum) {
case A:
return 16;
case B:
return 42;
}
/* => missing return value after switch, add default: or assert(0) */
}
Regards,
Pierrick
