On 02/10/2011 07:03 AM, Jiri Denemark wrote:
>> + va_start(list, caps);
>> + while ((flag = va_arg(list, int)) < QEMU_CAPS_LAST)
This is the bug I was talking about in the previous email. I should rather use
"enum qemuCapsFlags" instead of "int" in case someone passes
-fshort-enum
option to gcc which would result in the enum being represented as char rather
than int.
Ah, but char promotes to int, so you still end up getting the right
value from va_arg() (since varargs arguments are always passed via
default promotion rules). Not a bug, even under -fshort-enum. In fact,
gcc will warn if you do va_arg(list, enum xyz) when -fshort-enum is in
effect, since va_arg's second "argument" must be the promoted type.
> QEMU_CAPS_LAST as a terminal seems a bit awkward. Would it be
any
> better to require 0 to be the terminal?
The problem is that 0 is a valid flag value (QEMU_CAPS_KQEMU) addressing the
lowest bit. We could reserve the value for a terminal but in that case we
could never make use of the lowest bit in the bitmap. Not that it would make a
huge difference but QEMU_CAPS_LAST just seemed good enough to me :-) Also it's
kinda nice to have a call like
qemuCapsSetList(caps, QEMU_CAPS_1, QEMU_CAPS_2, ..., QEMU_CAPS_LAST)
Yeah, on second thought, I think this is as good as we can get.
Maybe it's worth an enhancement request to gcc to implement a new
attribute sentinel_value(value), where the existing sentinel(position)
maps to sentinel_value(NULL, position).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47702
But in the meantime, your approach worked out.
--
Eric Blake eblake(a)redhat.com +1-801-349-2682
Libvirt virtualization library
http://libvirt.org