Deallocating a data structure with a void* value

Question

I'm a beginner in C programming, and I'm sure this question is done and solved, but I cannot find much of an answer looking around. In my program, I have this implementation of a BST (Binary Search Tree) node:

typedef struct bstnode{
    char *key;
    void *value;
    struct bstnode *left;
    struct bstnode *right;
}bstnode;

In which I need value to be void* to utilize this same structure for different purposes. My fear, however, is that in doing so I am allowing for more possibilities of error and insability in my program. For example: in many cases, key points to a value that lives in the stack. Which is, well, fine. However, sometimes I need to perform dynamic allocation for key. And sometimes, value is also dynamically allocated. Which means that for every tree I create, I have to perform different deallocation routines (and, if the value is another dynamically allocated struct, I also need to make sure to deallocate that struct properly). Of course, I can keep track of which structure is which, but I fear that this might get out of hand and lead to memory leaks, and also to a less "mantainable" codebase (ex. having to make specific deallocation functions for specific use cases). My question is: is what I am doing bad practice? Is there a better way to go about it than having to write functions for every use case of the structure?

Answer 1

Managing lifetime of objects is a very big topic in programming, and so is transferring permission of who manages that object lifetime. There are multiple ways you can approach the problem.

• you can restrict that you use only dynamic allocation with standard C api.
• you can restrict that all values are created and destroyed by the user. You API only takes and returns the values to add and remove, and user manages memory. This overall restricts the API design to most simple functions. See bsd queue.h https://github.com/openbsd/src/blob/master/sys/sys/queue.h#L175 .
• You can pass an optional deallocation function and any other every time you need it. This results in very, very long function arguments each time you want to do something, but is good for "ad-hoc" functions.

void bsttree_free_cb(bsttree *tree, 
          void (*deallocate)(void *value, void *cookie),
          void *cookie) {
    for (every node to free) {
         if (deallocate) {
             deallocate(value, cookie);
         }
     }
}
void bsttree_free(bsttree *tree) {
    bsttree_free_cb(tree, NULL, NULL);
}

• You store deallocation function(-s) with the tree and call it when freeing the tree. This is a great overall solution. With cookie you can for example pass all the indexes of keys allocated on the stack and exclude them from free(). Overall, this is the way you could consider.

typedef struct bsttree {
    struct bstnode *head;
    void (*deallocate_value)(void *value, void *cookie);
    void (*deallocate_key)(void *key, void *cookie);
    void (*other_operation_value)(void *value, void *cookie);
    void *cookie;
} bsttree;

• You can store a deallocation function with each value and key and call it when deallocating. This will (greatly) increase the size of each element.

typedef struct bstnode {
    char *key;
    void *value;
    void (*deallocate_value)(void *value, void *cookie);
    void (*deallocate_key)(void *key, void *cookie);
    void (*other_operation_value)(void *value, void *cookie);
    void *cookie;
    struct bstnode *left;
    struct bstnode *right;
} bstnode;

• Finally, you write your code templated over each type. Using macros or code generation - either X macros or by replacing the macros - generate a function for each deallocation function and type that the user needs. You might be interested in https://github.com/stclib/STC/tree/master project.

You may also be interested in https://docs.gtk.org/glib/struct.Tree.html .

Answer 2

is what I am doing bad practice? Is there a better way to go about it than having to write functions for every use case of the structure?

These are good questions. You are being attentive to some important details.

The bottom line is that if you want to accommodate the most general case, where your nodes can contain pointers to values of varying type and provenance, then yes, you need somehow to provide information that allows your tree-manipulation routines to trigger the correct cleanup when required.

Some possibilities include:

• In each node, include a pointer to a function to use to deallocate the data for that node. This is among the most general alternatives available.

• Equip your tree-manipulation functions with parameters by which you can provide a (pointer to a) deallocation callback that they are to use to free the data of any node that is to be deleted. This is often sufficient, but it does not easily handle cases where different cleanup mechanisms are required for different data in the same tree.

• Provide a structure representing the tree overall, and attach appropriate cleanup functions to that. This allows for a cleaner API than the previous option, but it boils down to pretty much the same thing.

Answer 3

The most common way to handle this in data structures is to recognize that data structures will point to data that they didn't allocate and don't control.

So the common way to handle this is that in your C program you'll create objects that you can add to the data structures. But the layer of code that does the allocating should also do the deallocating. It should also avoid leaving a node in your BST pointing to the deallocated object.

So provide your bst api with a bst_delete(bsttree*, char* key) function that will remove the bstnode from the bst (and free it). But won't deallocate the actual object that points to. Because that's not it's job.

The calling code should call bst_delete() and then free() the object that needs to be deleted.

Don't add objects allocated on the stack to the bsttree unless the tree is also destroyed in the lifetime of the function that is using that stack context. When destroying the bsttree you'll need to delete all it's nodes to avoid a memory leak.