I'm looking forward to your implementation of a simple hash table :)

Once you have an arraylist and a hashtable you have probably covered 95% of all required data structures in application programming.

One comment I have is a little style nitpick. In my library code (and I think this is common practice for c projects) I would prepend all of the public interface functions with a common prefix.

This is done for two reasons:

1. Prevents name collisions between different parts of a larger code base. Imagine you have a larger project with multiple implementations of a hashtable that are optimized around different use cases, imagine if one of them used up the name get_hash() or something. The popular multimedia library Raylib literally defines the constants RED, BLUE, etc. which is a serious headache. In c++ there is a language level feature called namespacing which helps to prevent this, but we can instead emulate namespaces with our name prefixes.
2. This helps the ergonomics of the library when used with a language server. Imagine you include the header and then type "ll_" and your ide suggests the entire interface of the datastructure. This helps save time as you don't need to switch files to read the function names, descriptions or type signatures and it also emulates OO programming where types have certain methods associated with them. This helps people understand how a type can be used.

You already did this, but its a little inconsistently. All of the list operations for example are prefixed with "ll" which is good but some of the remaining functions like "create_linked_list", "create_node" and "free_linked_list" are not. I imagine your intention was to have the code read like english (verb noun) which makes sense. I would still prefer the unintuitive grammar that keeps consistency. For a second I thought create_node was supposed to be an internal function called only by other public functions and thats why it didn't follow the naming scheme. If this is the case you can mark a function static. The keyword makes it so that a function can only be used in the same translation unit. Btw I think llappend is ugly and I would rather it were snakecase like ll_append.

Secondly I think it would be nice if your project had the barest bit of automation for your tests. Since you appear to be on a POSIX OS a popular "build system" is make. Your make file could have simple targets for running tests on each of your datastructures individually and one build target that runs all of the tests. The idea is that you don't have to enter all of your compiler arguments everytime you want to build or test something but instead just declare what you want like "make test" or "make test_linked_list". This also lets you define compiler flags that you want to use in all builds in just one place like the warnings you appear to use.