On Wed, Feb 10, 2010 at 10:51:31AM +0000, Daniel P. Berrange wrote: > On Wed, Feb 10, 2010 at 11:45:45AM +0100, Matthias Bolte wrote: > > 2010/2/10 Daniel Veillard <veillard@xxxxxxxxxx>: > > > On Tue, Feb 09, 2010 at 07:04:24PM +0000, Daniel P. Berrange wrote: > > >> The QEMU flags are commonly stored as a signed or unsigned int, > > >> allowing only 31 flags. This limit is rather close, so to aid > > >> future patches, change it to a 64-bit int > > >> > > >> * src/qemu/qemu_conf.c, src/qemu/qemu_conf.h, src/qemu/qemu_driver.c, > > >> tests/qemuargv2xmltest.c, tests/qemuhelptest.c, tests/qemuxml2argvtest.c: > > >> Use 'unsigned long long' for QEMU flags > > >> --- > > > > > > > > ACK, that was something I was about to look at :-) > > > hopefully the enum definition for the flags will allow to go over > > > 32 bits too, I think the patch should also change all the > > > QEMUD_CMD_FLAG_ in /src/qemu/qemu_conf.h to be redefined from > > > (1 << x) into (1UUL << x), > > > > > > Daniel > > > > > > > I missed the fact that the flags are defined as enum members. This > > maybe an issue. IIRC enum members are ints. We should test this to > > make sure it works as expected on 32bit and 64bit systems. > > We're not ever declaring instances of the enum type, only using it as a > convenient way to define the constants. So provided we add '1UUL' as > DV suggests, we should be fine. I just tested and confirmed that on 32-bit when we start adding values to the enum >= 32 we will need to make it use 1ULL. The compiler actually identifies & warns about this so you can't miss it :-) Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list