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(a)redhat.com +1-801-349-2682
Libvirt virtualization library
http://libvirt.org