On 02/09/2011 09:01 AM, Jiri Denemark wrote:
---
src/libvirt_private.syms | 1 +
src/util/bitmap.c | 32 +++++++++++++++++++++++++++++++-
src/util/bitmap.h | 3 +++
3 files changed, 35 insertions(+), 1 deletions(-)
+char *virBitmapString(virBitmapPtr bitmap)
+{
+ virBuffer buf = VIR_BUFFER_INITIALIZER;
+ size_t sz;
+
+ virBufferAddLit(&buf, "0x");
+
+ sz = (bitmap->size + VIR_BITMAP_BITS_PER_UNIT - 1) /
+ VIR_BITMAP_BITS_PER_UNIT;
+
+ for ( ; sz > 0; sz--)
+ virBufferVSprintf(&buf, "%08x", bitmap->map[sz - 1]);
I probably would have written:
while (sz--)
virBufferVSprintf(&buf, "%08x", bitmap->map[sz]);
since sz is guaranteed to be non-zero to start with. But your way
works, and the compiler (hopefully) generates the same code (when
optimizing).
Problem - "%08x" is not portable. bitmap->map[x] is a uint32_t, which
means we need to use "%08"PRIx32 (since some platforms declare uint32_t
as long rather than int) to avoid a gcc warning.
For that matter, why did we make the bitset use uint32_t as the
underlying type, instead of just using long? We already have macros
VIR_BITMAP_BITS_PER_UNIT that make the rest of the code immune to size
changes, if we resize the bitmap to 64-bits on LP64 (like x86_64) while
keeping it at 32-bits on ILP32 (like i686). Of course, making that
change would mean that this new code would need to use
"%0*lx",VIR_BITMAP_BITS_PER_UNIT/4,bitmap->map[x].
I like the patch, but think it needs a v2.
--
Eric Blake eblake(a)redhat.com +1-801-349-2682
Libvirt virtualization library
http://libvirt.org