Re: [libvirt] [PATCH 03/19] qemu: monitor: Extract data about dirty-bimaps in qemuMonitorBlockGetNamedNodeData
On Thu, Dec 12, 2019 at 12:30:54 -0600, Eric Blake wrote:
On 12/12/19 11:18 AM, Peter Krempa wrote:
> We will need to inspect the presence and attributes for dirty bitmaps.
> Extract them when processing reply of query-named-block-nodes.
>
> Signed-off-by: Peter Krempa <pkrempa(a)redhat.com>
> ---
> src/qemu/qemu_monitor.h | 15 ++++++++
> src/qemu/qemu_monitor_json.c | 74 ++++++++++++++++++++++++++++++++++++
> 2 files changed, 89 insertions(+)
>
> +static void
> +qemuMonitorJSONBlockGetNamedNodeDataBitmaps(virJSONValuePtr bitmaps,
> + qemuBlockNamedNodeDataPtr data)
> +{
> + size_t nbitmaps = virJSONValueArraySize(bitmaps);
> + size_t i;
> +
> + data->bitmaps = g_new0(qemuBlockNamedNodeDataBitmapPtr, nbitmaps);
> +
> + for (i = 0; i < nbitmaps; i++) {
> + virJSONValuePtr bitmap = virJSONValueArrayGet(bitmaps, i);
> + qemuBlockNamedNodeDataBitmapPtr tmp;
> +
> + if (!bitmap)
> + continue;
Can bitmap ever be NULL? (We could assert that it is not, given our correct
usage of the API - except that we aren't using asserts). But doesn't hurt
to leave the check in.
AFAIK the JSON parser guarantees that it's not NULL, but given that the
return value of virJSONValueArrayGet is checked in many places I think
it would make static analyzers think it might return NULL and start
moaning.
Reviewed-by: Eric Blake <eblake(a)redhat.com>
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
--
libvir-list mailing list
libvir-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list