hashtable_remove disrupts hashtable_find_slot
If you remove an entry using hashtable_remove, you set its key = NULL. But if you then call hashtable_find_slot, and it linearly probes to the site of the deleted entry, seeing key = NULL will make the routine think this is the end of the linear probing chain, and the routine will falsely return the claim that the key was not found, instead of continuing to search past the removed entry.
A quick fix is to set a removed entry's key to some arbitrary value, say "XYZZY" or "\0", and to ban both NULL and "\0" from being permissible keys in the hashtable.
Thanks @opoudjis I looked into this and according to the explanation I found on wikipedia the two possible solutions are
- moving a later entry into the empty slot where the deletion took place (more complicated to implement)
- use a flag value as you suggest (easier to implement but doesn't free the slot and requires a flag value)
Right now I'm leaning towards the first solution as the more ideal one. I'm goinig to look into how to implement it.