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@xxxxxxxxxx +1-801-349-2682 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