On Fri, Mar 06, 2015 at 01:01:13PM -0700, Eric Blake wrote:
On 03/06/2015 10:02 AM, Ján Tomko wrote:
> Most of the callers use the pattern:
> bool b;
> ignore_value(virBitmapGetBit(.., &b));
> if (b) {
> ...
> }
>
> And the rest treats the failure (which can only happen
> when the requested bit is out of bitmap bounds) the same
> as they treat a 'false' bit.
Blindly returning false for out of bounds may work for some (most?)
callers, but I still wonder if we should expose the full bounds-checking
version under a different name, and/or expose a variant that lets the
caller specify the default value to return for an out-of-bounds
reference. That is, while you've made the common case short, I wonder
if we need the extra control for correctness elsewhere.
From the 23 callers in this patch:
10 explicitly ignore_value
5 are in a for loop from 0 to virBitmapSize (virProcessSetAffinity,
nodeCapsInitNUMA, virDomainSnapshotAlignDisks, libxlDomainGetVcpuPinInfo)
1 checks the range before calling GetBit (virPortAllocatorSetUsed)
1 loops against the bitmap range (virPortAllocatorAcquired)
I think these don't need any bounds-checking
2 of them take an enum as an argument (*CapsGet), I don't think we need
a special case for QEMU_CAPS_LAST either.
qemuBuildMemoryBackendStr admits to asking for out-of-range bits, so it
would require checking the bounds up front, or a default of 'false'.
In the rest of the callers, out-of-bounds queries are programming bugs,
but since the origins of their indexes are not so straightforward,
perhaps those should keep using the range-checking version.
So there's only one caller where a default of 'false' makes sense.
I think a function named virBitmapIsBitSet could return false on
out-of-range (how can it be set if it's not in the bitmap?)
I'm not outright rejecting this patch, but I'm also not sure
if it is
the right move to take - is our attempt at bounds-checking in order to
prevent programming bugs helping us avoid bugs (then this patch is
losing that safety), or is it just causing needless noise of boilerplate
(most callers using ignore_value, in which case this patch is the right
thing). Anyone else with an opinion?
In the meantime I've pushed the other two acked patches.
Jan