On 10/27/2015 02:21 AM, Markus Armbruster wrote: > Eric Blake <ebl...@redhat.com> writes: > >> Now that we have separated union tag values from colliding with >> non-variant C names, by naming the union 'u', we should reserve >> this name for our use. Note that we want to forbid 'u' even in >> a struct with no variants, because it is possible for a future >> qemu release to extend QMP in a backwards-compatible manner while >> converting from a struct to a flat union. Fortunately, no >> existing clients were using this member name. If we ever find >> the need for QMP to have a member 'u', we could at that time >> relax things, perhaps by having c_name() munge the QMP member to >> 'q_u'. >> >> Note that we cannot forbid 'u' everywhere (by adding the >> rejection code to check_name()), because the existing QKeyCode >> enum already uses it; therefore we only reserve it as a struct >> type member name. >> >> Signed-off-by: Eric Blake <ebl...@redhat.com> >> >> --- >> v11: commit message tweaks, use c_name(), tweak test names
>> - if c_name(key).startswith('has_'):
>> + if c_name(key, False) == 'u' or c_name(key).startswith('has_'):
>
> Slightly odd: new c_name() has protect=False, the existing one doesn't.
> While we don't really need protect=False, it feels a bit cleaner. If
> you like, I can add it to the existing one when it gets added in PATCH
> 05.
You're right - either both places need it, or neither place does.
Argument _for_ using c_name(, False): that's what we do in check_name()
when looking for 'q_', because we have to (if we use the default
c_name(, True), then the name gets munged and starts with q_ even though
the original did not). So even though we don't munge 'u' or 'has_' now,
if c_name() starts munging them in the future, consistently using
c_name(, False) here will protect us. So yes, make the change in patch 5.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
