ref.c: do not change ref count when release function is not set

This is the case of the null value singleton, bt_value_null, on which
you can call bt_get() and bt_put() and they should have no effect.
Before this patch, we can see log messages of the ref count going from 0
to 18446744073709551615 and other weird, huge values.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

diff --git a/lib/ref.c b/lib/ref.c
index 3a9cb61c60f1c4af99bc23d7bcff7274e690f809..153146af4622484e2c6437220c364012d36fb37e 100644 (file)
--- a/lib/ref.c
+++ b/lib/ref.c
@@ -38,6 +38,10 @@ void *bt_get(void *ptr)
                goto end;
        }
 
+       if (unlikely(!obj->ref_count.release)) {
+               goto end;
+       }
+
        if (unlikely(obj->parent && bt_object_get_ref_count(obj) == 0)) {
                BT_LOGV("Incrementing object's parent's reference count: "
                        "addr=%p, parent-addr=%p", ptr, obj->parent);
@@ -49,6 +53,7 @@ void *bt_get(void *ptr)
                ptr,
                obj->ref_count.count, obj->ref_count.count + 1);
        bt_ref_get(&obj->ref_count);
+
 end:
        return obj;
 }
@@ -61,6 +66,10 @@ void bt_put(void *ptr)
                return;
        }
 
+       if (unlikely(!obj->ref_count.release)) {
+               return;
+       }
+
        BT_LOGV("Decrementing object's reference count: %lu -> %lu: "
                "addr=%p, cur-count=%lu, new-count=%lu",
                obj->ref_count.count, obj->ref_count.count - 1,