Consider adding more HASH_FIND_XX for standard INT/UINT types

[depler]

I was breaking my head why this code not working as expected:

uint16_t uid = 0;
HASH_FIND_INT(head, &uid , item);

Until I did this:

#define HASH_FIND_UINT16(head,findint,out) HASH_FIND(hh,head,findint,sizeof(uint16_t),out)
#define HASH_ADD_UINT16(head,intfield,add) HASH_ADD(hh,head,intfield,sizeof(uint16_t),add)

Please append additional macros for standard INT/UINT types

[Quuxplusone]

I'm not inclined to add HASH_FIND_SHORT, HASH_FIND_UINT32_T, etc. etc.; that doesn't seem worth it, since someone who knows about this problem will simply use the general-purpose HASH_FIND in the first place. But it's pretty awful that HASH_FIND_INT(head, &uid, item) compiles silently to the wrong behavior!

We could mitigate this by changing the macro as follows:

 #define HASH_FIND_INT(head,findint,out)                                          \
-    HASH_FIND(hh,head,findint,sizeof(int),out)
+    HASH_FIND(hh,head,findint,sizeof(int[sizeof(*(findint)) == sizeof(int) ? 1 : -1]),out)

This says "If the user gave us a pointer of the form &uid but sizeof(*&uid) isn't the same as sizeof(int), then compile-time fail."
I think the problem with this would be backward compatibility. Today, this works:

    int uid = 42;
    unsigned char *p = (unsigned char*)&uid;
    HASH_FIND_INT(head, p, item);

But it wouldn't work after the above change. Therefore I don't think we can actually make the above change, at least not by default.