Yeah, but it's pretty lame since you have to specify the size of the table up front and can't change it later. They didn't implement the hard stuff!
- There is only one global hash table for the whole process! If you want individual hash tables you need to use implementation-specific extensions (hcreate_r().)
- There is no way to remove a key from a hash table. No implementation I know of provides an extension to do it. If you want to truly remove a key you must destroy and rebuild the table.
- There is no requirement for a means to grow the table. On some platforms it's possible to run out of space. If you want to truly grow you must destroy and rebuild the table.
- There is no standard way to free keys or data stored in the table. Destroying the table leaks all contents; you must keep track of keys and data externally and free them yourself. Only OpenBSD frees keys by default, and only NetBSD has extensions to call callbacks to free keys and data.
- Keys must be strings. You cannot provide custom types or void pointers as keys. There is no way to specify custom hash or comparison functions. The quality of the hash function is unspecified.
- When using ENTER, you may not want to allocate the key unless it is necessary to insert a new entry. Since the given key is inserted directly, it's not necessarily safe to use a stack-allocated buffer for lookups. It's awkward to replace the key with an allocation after insertion and it's unclear whether it's allowed.
This doesn't even get into incompatibilities between the various implementations. You will encounter all of the above flaws even if your only target is glibc.
No one should ever be encouraged to use POSIX hash tables. They should be deprecated and we should all just pretend they don't exist.
Or at the very least just deprecate the old one. I can't remember ever seeing it used in code.
Yes, I realize the lookup would get complicated.
There is a GNU extension that lets you have more than one table.