2011/6/6 Eric Blake <eblake@xxxxxxxxxx>: > 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@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list