| commit | 54ba5a1a16c0306bda1c304a341b9e4e7ab44684 | |
| author | Junio C Hamano <gitster@pobox.com> | |
| Tue, 2 Aug 2016 18:04:05 +0000 (2 11:04 -0700) | ||
| committer | Junio C Hamano <gitster@pobox.com> | |
| Tue, 2 Aug 2016 21:34:17 +0000 (2 14:34 -0700) | ||
| tree | e324f56a1fe38f384dca49dc14f822afaa8a852d | treesnapshot (tar.gz zip) |
| parent | e46579643d56162299b1756b70d418005351b256 | commitdiff |
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 <gitster@pobox.com>
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 <gitster@pobox.com>
| Documentation/technical/api-hashmap.txt | diffblobblamehistory |