Makes wmem_map more similar to g_hash.
Change-Id: Ia17a19ab0be8e07fbb64801d54db2ba8217a7fea
Reviewed-on: https://code.wireshark.org/review/15020
Petri-Dish: Anders Broman <a.broman58@gmail.com>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
"if (G_UNLIKELY(...))" triggers an extraneous parentheses warning when
compiling with XCode's clang-500.2.75. From looking at the macro
definition we *should* be able to get rid of the outer parentheses
everywhere.
Change-Id: I710e1cc391e1167c1243c4ddb032f2831f0a9498
Reviewed-on: https://code.wireshark.org/review/1432
Reviewed-by: Gerald Combs <gerald@wireshark.org>
For 'x' equal to 0, HASH() macro also returns 0 which makes wmem map O(n).
When random generator will return 0 just use 1.
Change-Id: If484091352a719aea27135a705d37ff4c184a13b
Reviewed-on: https://code.wireshark.org/review/1387
Reviewed-by: Michael Mann <mmann78@netscape.net>
This has two expected uses:
- Many current users of wmem_tree don't actually need the predecessor lookup
it provides (the lookup_le function family). A hash map provides straight
insertion and lookup much more efficiently than a wmem_tree when predecessor
lookup isn't needed.
- Many current users of glib's hash table and hash functions use untrusted data
for keys, making them vulnerable to algorithmic complexity attacks. Care has
been taken to make this implementation secure against such attacks, so it
should be used whenever data is untrusted.
In my benchmarks it is measurably slower than GHashTable, but not excessively
so. Given the additional security it provides this seems like a reasonable
trade-off (and it is still faster than a wmem_tree).
Change-Id: I2d67a0d06029f14c153eaa42d5cfc774aefd9918
Reviewed-on: https://code.wireshark.org/review/1272
Reviewed-by: Evan Huus <eapache@gmail.com>
Dario Lombardo