src/oidmap.h


Log

Author Commit Date CI Message
Patrick Steinhardt bd66925a 2018-12-01T10:29:32 oidmap: remove legacy low-level interface Remove the low-level interface that was exposing implementation details of `git_oidmap` to callers. From now on, only the high-level functions shall be used to retrieve or modify values of a map. Adjust remaining existing callers.
Patrick Steinhardt 2e0a3048 2019-01-23T10:48:55 oidmap: introduce high-level setter for key/value pairs Currently, one would use either `git_oidmap_insert` to insert key/value pairs into a map or `git_oidmap_put` to insert a key only. These function have historically been macros, which is why their syntax is kind of weird: instead of returning an error code directly, they instead have to be passed a pointer to where the return value shall be stored. This does not match libgit2's common idiom of directly returning error codes.Furthermore, `git_oidmap_put` is tightly coupled with implementation details of the map as it exposes the index of inserted entries. Introduce a new function `git_oidmap_set`, which takes as parameters the map, key and value and directly returns an error code. Convert all trivial callers of `git_oidmap_insert` and `git_oidmap_put` to make use of it.
Patrick Steinhardt 9694ef20 2018-12-17T09:01:53 oidmap: introduce high-level getter for values The current way of looking up an entry from a map is tightly coupled with the map implementation, as one first has to look up the index of the key and then retrieve the associated value by using the index. As a caller, you usually do not care about any indices at all, though, so this is more complicated than really necessary. Furthermore, it invites for errors to happen if the correct error checking sequence is not being followed. Introduce a new high-level function `git_oidmap_get` that takes a map and a key and returns a pointer to the associated value if such a key exists. Otherwise, a `NULL` pointer is returned. Adjust all callers that can trivially be converted.
Patrick Steinhardt 7e926ef3 2018-11-30T12:14:43 maps: provide a uniform entry count interface There currently exist two different function names for getting the entry count of maps, where offmaps offset and string maps use `num_entries` and OID maps use `size`. In most programming languages with built-in map types, this is simply called `size`, which is also shorter to type. Thus, this commit renames the other two functions `num_entries` to match the common way and adjusts all callers.
Patrick Steinhardt 351eeff3 2019-01-23T10:42:46 maps: use uniform lifecycle management functions Currently, the lifecycle functions for maps (allocation, deallocation, resize) are not named in a uniform way and do not have a uniform function signature. Rename the functions to fix that, and stick to libgit2's naming scheme of saying `git_foo_new`. This results in the following new interface for allocation: - `int git_<t>map_new(git_<t>map **out)` to allocate a new map, returning an error code if we ran out of memory - `void git_<t>map_free(git_<t>map *map)` to free a map - `void git_<t>map_clear(git<t>map *map)` to remove all entries from a map This commit also fixes all existing callers.
Patrick Steinhardt 18cf5698 2018-12-01T09:37:40 maps: provide high-level iteration interface Currently, our headers need to leak some implementation details of maps due to their direct use of indices in the implementation of their foreach macros. This makes it impossible to completely hide the map structures away, and also makes it impossible to include the khash implementation header in the C files of the respective map only. This is now being fixed by providing a high-level iteration interface `map_iterate`, which takes as inputs the map that shall be iterated over, an iterator as well as the locations where keys and values shall be put into. For simplicity's sake, the iterator is a simple `size_t` that shall initialized to `0` on the first call. All existing foreach macros are then adjusted to make use of this new function.
Patrick Steinhardt c50a8ac2 2018-12-01T08:59:24 maps: use high-level function to check existence of keys Some callers were still using the tightly-coupled pattern of `lookup_index` and `valid_index` to verify that an entry exists in a map. Instead, use the more high-level `exists` functions to decouple map users from its implementation.
Patrick Steinhardt 84a089da 2018-12-01T08:50:36 maps: provide return value when deleting entries Currently, the delete functions of maps do not provide a return value. Like this, it is impossible to tell whether the entry has really been deleted or not. Change the implementation to provide either a return value of zero if the entry has been successfully deleted or `GIT_ENOTFOUND` if the key could not be found. Convert callers to the `delete_at` functions to instead use this higher-level interface.
Patrick Steinhardt f2f5ec84 2018-11-23T19:27:09 khash: move khash include into implementation files The current map implementations directly include the "khash.h" headers into their own headers to make available a set of static functions, defines et cetera. Besides leaking the complete khash namespace into files wherever khashes are used, this also triggers Clang's -Wunused-function warnings when some of the static functions are not being used at all. Fix the issue by moving the includes into the respective map implementation files. Add forward declares for all the map types to make them known.
Patrick Steinhardt 5bfb3b58 2018-11-23T18:48:40 khash: implement map-specific foreach macros The current foreach map macros simply redirect to the type-indifferent `kh_foreach` macro. As this type-indifferent macro directly accesses the structures, the current implementation makes it impossible to make the stuctures private to the implementation only. And making them private is required to move out the khash include into the implementations to decrease the namespace leak.
Patrick Steinhardt 382b668b 2018-11-23T18:38:18 khash: implement begin/end via functions instead of macros Right now, the `git_*map_begin()` and `git_*map_end()` helpers are implemented via macros which simply redirect to `kh_begin` and `kh_end`. As these macros refer to members of the map structures, they make it impossible to move the khash include into the implementation files. Implement these helpers as real functions instead to further decouple the headers from implementations.
Patrick Steinhardt 0c7f49dd 2017-06-30T13:39:01 Make sure to always include "common.h" first Next to including several files, our "common.h" header also declares various macros which are then used throughout the project. As such, we have to make sure to always include this file first in all implementation files. Otherwise, we might encounter problems or even silent behavioural differences due to macros or defines not being defined as they should be. So in fact, our header and implementation files should make sure to always include "common.h" first. This commit does so by establishing a common include pattern. Header files inside of "src" will now always include "common.h" as its first other file, separated by a newline from all the other includes to make it stand out as special. There are two cases for the implementation files. If they do have a matching header file, they will always include this one first, leading to "common.h" being transitively included as first file. If they do not have a matching header file, they instead include "common.h" as first file themselves. This fixes the outlined problems and will become our standard practice for header and source files inside of the "src/" from now on.
Patrick Steinhardt 94af9155 2017-03-20T09:01:18 map: remove `*map_free` macros The `map_free` functions were not implemented as functions but instead as macros which also set the map to NULL. While this is most certainly sensible in most cases, we should prefer the more obvious behavior, namingly leaving the map pointer intact. Furthermore, this macro has been refactored incorrectly during the map-refactorings: the two statements are not actually grouped together by a `do { ... } while (0)` block, as it is required for macros to match the behavior of functions more closely. This has led to at least one subtle nesting error in `pack-objects.c`. The following code block ``` if (pb->object_ix) git_oidmap_free(pb->object_ix); ``` would be expanded to ``` if (pb->object_ix) git_oidmap__free(pb->object_ix); pb->object_ix = NULL; ``` which is not what one woudl expect. While it is not a bug here as it would simply become a no-op, the wrong implementation could lead to bugs in other occasions. Fix this by simply removing the macro altogether and replacing it with real function calls. This leaves the burden of setting the pointer to NULL afterwards to the caller, but this is actually expected and behaves like other `free` functions.
Patrick Steinhardt 0d716905 2017-01-27T15:23:15 oidmap: remove GIT__USE_OIDMAP macro
Patrick Steinhardt 659f5d07 2017-01-27T14:53:23 oidmap: convert macros to functions
Patrick Steinhardt 73028af8 2017-01-27T14:20:24 khash: avoid using macro magic to get return address
Patrick Steinhardt 85d2748c 2017-01-27T14:05:10 khash: avoid using `kh_key`/`kh_val` as lvalue
Patrick Steinhardt f31cb45a 2017-01-25T15:31:12 khash: avoid using `kh_put` directly
Patrick Steinhardt a8cd560b 2017-01-25T14:41:17 khash: avoid using `kh_del` directly
Patrick Steinhardt 71a54317 2017-01-25T14:32:23 khash: avoid using `kh_key` directly
Patrick Steinhardt 76e671a6 2017-01-25T14:20:56 khash: avoid using `kh_exist` directly
Patrick Steinhardt 64e46dc3 2017-01-25T14:14:12 khash: avoid using `kh_end` directly
Patrick Steinhardt 036daa59 2017-01-25T14:11:42 khash: use `git_map_exists` where applicable
Edward Thomson 220d6f8a 2015-09-11T20:06:14 mempack: expose clear function
Stefan Widgren c8e02b87 2015-02-15T21:07:05 Remove extra semicolon outside of a function Without this change, compiling with gcc and pedantic generates warning: ISO C does not allow extra ‘;’ outside of a function.
Edward Thomson 650e45f6 2015-02-11T17:51:17 Update `khash.h` to pull request 42 https://github.com/attractivechaos/klib/pull/42/files introduces `kreallocarray`. Hook that up as our `git__reallocarray`.
nulltoken 3a728fb5 2012-11-13T16:35:24 object: introduce git_describe_object()
nulltoken de1e81aa 2012-11-15T09:08:30 oidmap: Enhance the khash wrapper
Russell Belfer 78606263 2013-04-15T00:05:44 Add callback to git_objects_table This adds create and free callback to the git_objects_table so that more of the creation and destruction of objects can be table driven instead of using switch statements. This also makes the semantics of certain object creation functions consistent so that we can make better use of function pointers. This also fixes a theoretical error case where an object allocation fails and we end up storing NULL into the cache.
Vicent Marti 5df18424 2013-04-01T19:38:23 lol this worked first try wtf
Edward Thomson 359fc2d2 2013-01-08T17:07:25 update copyrights
Michael Schubert f6b26e77 2012-07-27T10:53:09 git_oid_cmp: inline memcmp by hand to optimize git.git uses an inlined hashcmp function instead of memcmp, since it performes much better when comparing hashes (most hashes compared diverge within the first byte). Measurements and rationale for the curious reader: http://thread.gmane.org/gmane.comp.version-control.git/172286
Russell Belfer 39b8e047 2012-07-12T11:52:10 Missed a couple of khash inline dependencies
Russell Belfer c2b67043 2012-04-25T15:20:28 Rename git_khash_str to git_strmap, etc. This renamed `git_khash_str` to `git_strmap`, `git_hash_oid` to `git_oidmap`, and deletes `git_hashtable` from the tree, plus adds unit tests for `git_strmap`.