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(a)redhat.com>:
> > 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 :|