Skip to content

Commit 54ba5a1

Browse files
committed
hashmap: clarify that hashmap_entry can safely be discarded
The API documentation said that the hashmap_entry structure to be embedded in the caller's structure is to be treated as opaque, which left the reader wondering if it can safely be discarded when it no longer is necessary. If the hashmap_entry structure had references to external resources such as allocated memory or an open file descriptor, merely free(3)ing the containing structure (when the caller's structure is on the heap) or letting it go out of scope (when it is on the stack) would end up leaking the external resource. Document that there is no need for hashmap_entry_clear() that corresponds to hashmap_entry_init() to give the API users a little bit of peace of mind. Signed-off-by: Junio C Hamano <[email protected]>
1 parent e465796 commit 54ba5a1

File tree

1 file changed

+5
-0
lines changed

1 file changed

+5
-0
lines changed

Documentation/technical/api-hashmap.txt

Lines changed: 5 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -104,6 +104,11 @@ If `free_entries` is true, each hashmap_entry in the map is freed as well
104104
`entry` points to the entry to initialize.
105105
+
106106
`hash` is the hash code of the entry.
107+
+
108+
The hashmap_entry structure does not hold references to external resources,
109+
and it is safe to just discard it once you are done with it (i.e. if
110+
your structure was allocated with xmalloc(), you can just free(3) it,
111+
and if it is on stack, you can just let it go out of scope).
107112

108113
`void *hashmap_get(const struct hashmap *map, const void *key, const void *keydata)`::
109114

0 commit comments

Comments
 (0)