Eliminate HASH_FCN; change the handling of HASH_FUNCTION to match HASH_KEYCMP.
The behavior of these two "supported" codepaths has not changed at all:
#define HASH_FUNCTION foo
#include <uthash.h>
HASH_VALUE(...) // expanded to foo(...)
#include <uthash.h>
HASH_VALUE(...) // expanded to HASH_JEN(...)
However, some pathological codepaths have changed.
The old behavior was that if you had defined `HASH_FUNCTION` before
including "uthash.h", then when you called `HASH_VALUE` it would expand
to `HASH_FCN` which would expand to `HASH_FUNCTION`. But if you hadn't
defined `HASH_FUNCTION` before including "uthash.h", then when you
called `HASH_VALUE` it would expand to `HASH_FCN` which would expand
to `HASH_JEN`.
#define HASH_FUNCTION foo
#include <uthash.h>
#undef HASH_FUNCTION
#define HASH_FUNCTION bar
HASH_VALUE(...) // expanded to bar(...)
#include <uthash.h>
#undef HASH_FUNCTION // unneeded, HASH_FUNCTION is undefined
#define HASH_FUNCTION bar
HASH_VALUE(...) // expanded to HASH_JEN(...)
The new behavior is that `HASH_VALUE` expands to `HASH_FUNCTION`;
and separately, if you don't define `HASH_FUNCTION` before including
"uthash.h", we'll default it to `HASH_JEN`.
#define HASH_FUNCTION foo
#include <uthash.h>
#undef HASH_FUNCTION
#define HASH_FUNCTION bar
HASH_VALUE(...) // expanded to bar(...)
#include <uthash.h>
#undef HASH_FUNCTION // needed, HASH_FUNCTION is defined to HASH_JEN
#define HASH_FUNCTION bar
HASH_VALUE(...) // expanded to bar(...)
This is the way `HASH_KEYCMP` (formerly known as `uthash_memcmp`) has
always worked. Since these two customization points are used in similar
ways, it'll be nice to have their codepaths work alike instead of
subtly different. Also, this gets rid of one level of macro indirection
(`HASH_FCN` no longer exists), hooray!
parent
f0e1bd9b
Please register or sign in to comment