Fortunately, this is not causing any problems now because glib
does this check for us when calling this function via attribute
cleanup. But in future commit we will explicitly call this
function over a struct member that might be NULL.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
---
 src/conf/capabilities.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/conf/capabilities.c b/src/conf/capabilities.c
index 4fac59e6f7..a782d92956 100644
--- a/src/conf/capabilities.c
+++ b/src/conf/capabilities.c
@@ -184,6 +184,9 @@ virCapabilitiesFreeStoragePool(virCapsStoragePoolPtr pool)
 void
 virCapabilitiesHostNUMAUnref(virCapsHostNUMAPtr caps)
 {
+    if (!caps)
+        return;
+
     if (g_atomic_int_dec_and_test(&caps->refs)) {
         g_ptr_array_unref(caps->cells);
 
-- 
2.24.1

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

On 12/18/19 5:37 AM, Michal Privoznik wrote:
> Fortunately, this is not causing any problems now because glib
> does this check for us when calling this function via attribute
> cleanup. But in future commit we will explicitly call this

nit: "But in a future commit ..."


--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list