2011/6/6 Eric Blake <ebl...@redhat.com>: > Detected by Coverity. cpumap was allocated with a value of > (unsigned short)*(int), which is an int computation, and then > promotes to size_t. On a 64-bit platform, this fails if bit > 32 of the product is set (because of sign extension giving > a HUGE value to malloc), even though a naive programmer would > assume that since the first value is unsigned, the product > is also unsigned and at most 4GB would be allocated. > > Won't bite in practice (the product should never be that large), > but worth using the right types to begin with, so that we are > now computing (unsigned short)*(size_t). > > * python/libvirt-override.c (libvirt_virDomainGetVcpus): Use > correct type. > --- > python/libvirt-override.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/python/libvirt-override.c b/python/libvirt-override.c > index 763df00..974decb 100644 > --- a/python/libvirt-override.c > +++ b/python/libvirt-override.c > @@ -414,7 +414,7 @@ libvirt_virDomainGetVcpus(PyObject *self ATTRIBUTE_UNUSED, > virDomainInfo dominfo; > virVcpuInfoPtr cpuinfo = NULL; > unsigned char *cpumap = NULL; > - int cpumaplen, i; > + size_t cpumaplen, i; > int i_retval; > > if (!PyArg_ParseTuple(args, (char *)"O:virDomainGetVcpus",
ACK. Matthias -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list