>>9,10 here
The more I think about what you're trying to accomplish, the more I realize that you and the people who have created similar libraries for C in the past are going completely against the grain regarding the strengths of C and falling into one of the major weaknesses of the languages.
General purpose data structure toolkits in C, including glib and friends, are all gargbage. And I'm afraid that anything you concoct will have no use other than to satisfy your curiosity. They have far worse performance compared to equivalents in the C++ Standard Library, due to function call overhead, pointer indirection with void pointers with the underlying objects allocated out-of-band, emphasis on linked lists and trees, and so on and so forth. And with C data structure toolkits, there's no easy way to abstract the underlying allocator like in C++... typically, everything is hardcoded to call malloc/free or global function pointers to functions with the same signature.
You want a dynamic array of objects of a given structure type?
Given:
typedef struct
{
int value;
char* name;
/* some other shit */
}
entry;
How fucking hard is it to write:
[code]
typedef struct
{
entry *entries;
size_t num_entries;
// whole bunch of other arrays and shit for all of the other data you want to keep track within this subsystem or module of the program
}
higher_level_data_structure;
higher_level_data_structure ctx;
ctx.num_entries = /* whatever */;
ctx.entries = (entry *)malloc(sizeof(entry) * ctx.num_entries);
// initialize other data within ctx here
And changing it to use a linear arena allocator instead of malloc isn't that difficult. On the otherhand dressing it up in a bunch of shit like glib doesn't add anything to your program.
As for things like associative data structures like trees or hash-maps, you don't need them for most thing. A lot of time, most of your data is immutable or constant, so you can just use qsort to sort your arrays and use bsearch (or a manual inlined binary-search loop, it's not that much code) to get O(log n) searches, like a tree, but with better performance due to better cache locality.
And where you actually need constant time insertion or removal, writing an optimized hard-coded associative hash-table with quadratic probing is only like 200 lines of code if you only implement the actual operations you need for your use cases. That's fucking nothing.
Stop fighting against the weaknesses of C and embrace the strengths.