Memory management and reference counting¶
Due to the nature of its domain, libcbor will need to work with heap memory. The stateless decoder and encoder don’t allocate any memory.
If you have specific requirements, you should consider rolling your own driver for the stateless API.
Using custom allocator¶
libcbor gives you with the ability to provide your own implementations of malloc
, realloc
, and free
. This can be useful if you are using a custom allocator throughout your application, or if you want to implement custom policies (e.g. tighter restrictions on the amount of allocated memory).
In order to use this feature, libcbor has to be compiled with the appropriate flags. You can verify the configuration using the CBOR_CUSTOM_ALLOC
macro. A simple usage might be as follows:
#if CBOR_CUSTOM_ALLOC
cbor_set_allocs(malloc, realloc, free);
#else
#error "libcbor built with support for custom allocation is required"
#endif
-
void cbor_set_allocs(_cbor_malloc_t custom_malloc, _cbor_realloc_t custom_realloc, _cbor_free_t custom_free)¶
Sets the memory management routines to use.
Only available when
CBOR_CUSTOM_ALLOC
is truthyNote
realloc implementation must correctly support NULL reallocation (see e.g. http://en.cppreference.com/w/c/memory/realloc)
Warning
This function modifies the global state and should therefore be used accordingly. Changing the memory handlers while allocated items exist will result in a
free
/malloc
mismatch. This function is not thread safe with respect to both itself and all the other libcbor functions that work with the heap.- param custom_malloc:
malloc implementation
- param custom_realloc:
realloc implementation
- param custom_free:
free implementation
Reference counting¶
As CBOR items may require complex cleanups at the end of their lifetime, there is a reference counting mechanism in place. This also enables very simple GC when integrating libcbor into managed environment. Every item starts its life (by either explicit creation, or as a result of parsing) with reference count set to 1. When the refcount reaches zero, it will be destroyed.
Items containing nested items will be destroyed recursively - refcount of every nested item will be decreased by one.
The destruction is synchronous and renders any pointers to items with refcount zero invalid immediately after calling the cbor_decref()
.
-
cbor_item_t *cbor_incref(cbor_item_t *item)¶
Increases the reference count by one.
No dependent items are affected.
- param item[incref]:
item the item
- return:
the input reference
-
void cbor_decref(cbor_item_t **item)¶
Decreases the reference count by one, deallocating the item if needed.
In case the item is deallocated, the reference count of any dependent items is adjusted accordingly in a recursive manner.
- param item[take]:
the item. Set to
NULL
if deallocated
-
void cbor_intermediate_decref(cbor_item_t *item)¶
Decreases the reference count by one, deallocating the item if needed.
Convenience wrapper for cbor_decref when its set-to-null behavior is not needed
- param item[take]:
the item
-
size_t cbor_refcount(const cbor_item_t *item)¶
Get the reference count.
Warning
This does not account for transitive references.
- param item[borrow]:
the item
- return:
the reference count
-
cbor_item_t *cbor_move(cbor_item_t *item)¶
Provides CPP-like move construct.
Decreases the reference count by one, but does not deallocate the item even if its refcount reaches zero. This is useful for passing intermediate values to functions that increase reference count. Should only be used with functions that
incref
their arguments.Warning
If the item is moved without correctly increasing the reference count afterwards, the memory will be leaked.
- param item[take]:
the item
- return:
the item with reference count decreased by one
-
cbor_item_t *cbor_copy(cbor_item_t *item)¶
Deep copy of an item.
All the reference counts in the new structure are set to one.
- param item[borrow]:
item to copy
- return:
new CBOR deep copy