...But I still have one problem: hash_put and hash_get are not symmetric. hash_put puts a void *value, but hash_get returns a HASHBUCKET. This looks wrong to me.
When returning the value directly, we couldn't have NULL value's - or better NULL values and no entry at all would have the same return result.
From the principle of least surprise, I suggest to let hash_get return a value pointer directly and have the ambiguity of NULL value and no entry, and have a hash_get_bucket which returns a pointer to the bucket.
void * hash_get(Interp * interpreter, HASH *hash, void *key);
HASHBUCKET * hash_get_bucket(Interp * interpreter, HASH *hash, void *key);
And to amplify what you are saying, I think it's okay for hash_get to be ambiguous as to whether or not the key exists, as long as there is a separate method for that--hash_key_exists or something. (I can't think of a case in user code where you'd need to do both in one call--in perl5 for example "exists" is a separate operator from hash lookup.)
An alternative (which may or may not a good one) would be to say that you can never actually store a NULL in a hash--at most you could store a PerlUndef or Null or whatever null-ish PMC. Then a NULL return unambiguously means that the key wasn't found. I could probably argue either for or against this.
JEff
