On 05/17/2010 12:09 PM, Jim Fehlig wrote:
--- src/util/util.c | 38 ++++++++++++++++++++++++++++++++++++++ src/util/util.h | 10 ++++++++++ 2 files changed, 48 insertions(+), 0 deletions(-)
diff --git a/src/util/util.c b/src/util/util.c index 26ac6ba..e600bef 100644 --- a/src/util/util.c +++ b/src/util/util.c @@ -2817,3 +2817,41 @@ int virBuildPathInternal(char **path, ...)
return ret; } + +/* would CHAR_BIT or such be better than explicit '8'? */ +#define VIR_BITMAP_BITS_PER_UNIT (sizeof(virBitmap) * 8)
In answer to the question, yes, #include <limits.h> and use CHAR_BIT (although it is guaranteed by POSIX to be 8).
+virBitmapPtr virBitmapAlloc(unsigned int size)
Why not size_t?
+{ + virBitmapPtr bitmap; + unsigned int sz = (size / VIR_BITMAP_BITS_PER_UNIT) + + (size % VIR_BITMAP_BITS_PER_UNIT);
Stefan already pointed out the bug here.
+ + if (VIR_ALLOC_N(bitmap, sz) < 0) + return NULL; + return bitmap; +} + +void virBitmapFree(virBitmapPtr bitmap) +{ + VIR_FREE(bitmap); +}
Another function to add to cfg.mk's list of free-like functions.
+ +void virBitmapSetBit(virBitmapPtr bitmap, unsigned int b) +{ + bitmap[VIR_BITMAP_UNIT_OFFSET(b)] |= (1 << VIR_BITMAP_BIT_OFFSET(b)); +} + +void virBitmapClearBit(virBitmapPtr bitmap, unsigned int b) +{ + bitmap[VIR_BITMAP_UNIT_OFFSET(b)] &= ~(1 << VIR_BITMAP_BIT_OFFSET(b)); +} + +int virBitmapGetBit(virBitmapPtr bitmap, unsigned int b)
bool instead of int
+{ + virBitmap bit = bitmap[VIR_BITMAP_UNIT_OFFSET(b)] & + (1 << VIR_BITMAP_BIT_OFFSET(b));
Should these interfaces add sanity checks that b is in range (that is, smaller than the original allocated size)? Do we want to support dynamically-growing bitsets? -- Eric Blake eblake@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org