Re: [PATCH 2/3] Return bool in virBitmapGetBit

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

Attachment: signature.asc
Description: Digital signature

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]