[libvirt] [RFC PATCH 1/6] util: Add API for converting virBitmap into printable string

[Eric Blake]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 619 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20110209/232ea0f8/attachment-0001.sig>