On 01/09/2013 07:07 PM, Laine Stump wrote: >>> >> According to Coverity's analysis this may not be true since it's >> "possible" to hit the "ret--" line (more than once) in virBitmapParse() >> while hitting either "ret++" line less times returning a negative value >> on the "success" path. The example Coverity had shows 6 passes through >> the loop, 4 negatives, 1 positive, and 1 nothing. >> >> Whether realistically this could be true, I am not sure. >> >> How Coverity determined what the value of 'cpuSet' is a mystery as the >> output I have doesn't show what's being used for parsing, just that we >> go through the loop 6 times. Perhaps something like "^1,^2,^3,4,^5,^6" >> where 1,2,3,4,5,6 pass the virBitmapIsSet() call changing the 'ret' >> value to -3. Except that we would have rejected '^1' outright up front. > > I don't think that is possible. In order for virBitmapIsSet() to return > true for a particular bit, that bit must be set, and in order for that > bit to be set, it must have been set in a previous iteration of this > same loop (remember that the bitmap is initialized to all empty at the > top of the function), which means that ret++ must have been executed. So > ret-- can't happen without a previous corresponding ret++, therefore the > value of ret can't be < 0. Maybe a well-placed: sa_assert(ret >= 0); will help Coverity learn a bit more of the logic flow, which proves that we cannot reach the success path with too many ret-- lines. > > If it was possible to have a return < 0 on success, that would be a bug > in the function that would need to be fixed. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list