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@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org