mirror of
https://gitlab.gnome.org/GNOME/glib.git
synced 2025-01-14 00:06:24 +01:00
GHashTable: Add a note about hash collisions
This commit is contained in:
parent
a3b91b3691
commit
030b3f25e3
18
glib/ghash.c
18
glib/ghash.c
@ -151,11 +151,19 @@
|
||||
* g_direct_hash() is also the appropriate hash function for keys
|
||||
* of the form <literal>GINT_TO_POINTER (n)</literal> (or similar macros).
|
||||
*
|
||||
* <!-- FIXME: Need more here. --> The hash values should be evenly
|
||||
* distributed over a fairly large range? The modulus is taken with the
|
||||
* hash table size (a prime number) to find the 'bucket' to place each
|
||||
* key into. The function should also be very fast, since it is called
|
||||
* for each key lookup.
|
||||
* <!-- FIXME: Need more here. --> A good hash functions should produce
|
||||
* hash values that are evenly distributed over a fairly large range.
|
||||
* The modulus is taken with the hash table size (a prime number) to
|
||||
* find the 'bucket' to place each key into. The function should also
|
||||
* be very fast, since it is called for each key lookup.
|
||||
*
|
||||
* Note that the hash functions provided by GLib have these qualities,
|
||||
* but are not particularly robust against manufactured keys that
|
||||
* cause hash collisions. Therefore, you should consider choosing
|
||||
* a more secure hash function when using a GHashTable with keys
|
||||
* that originate in untrusted data (such as HTTP requests).
|
||||
* Using g_str_hash() in that situation might make your application
|
||||
* vulerable to <ulink url="https://lwn.net/Articles/474912/">Algorithmic Complexity Attacks</ulink>.
|
||||
*
|
||||
* Returns: the hash value corresponding to the key
|
||||
*/
|
||||
|
Loading…
Reference in New Issue
Block a user