This commit makes macro function "ASSIGN_CONTAINER()" evaluates
to "(void)0". This is to avoid the 'clang' warning: "expression
result unused", since most of time, the final evaluated value
is not used.
Signed-off-by: Alex Wang <alexw@nicira.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
It seems that 'clang' compiler applies strict protection on pointer
dereference. And it causes unexpected execution in macro functions
like "HMAP_FOR_EACH()" and unit test failures. This commit fixes
this issue and pass all unit tests.
Co-authored-by: Ethan Jackson <ethan@nicira.com>
Signed-off-by: Alex Wang <alexw@nicira.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
Without this change, an initialization such as
const struct hmap map = HMAP_INITIALIZER(&map);
yields a compiler warning "initialization discards qualifiers from pointer
target type".
Signed-off-by: Ben Pfaff <blp@nicira.com>
Casts are sometimes necessary. One common reason that they are necessary
is for discarding a "const" qualifier. However, this can impede
maintenance: if the type of the expression being cast changes, then the
presence of the cast can hide a necessary change in the code that does the
cast. Using CONST_CAST, instead of a bare cast, makes these changes
visible.
Inspired by my own work elsewhere:
http://git.savannah.gnu.org/cgit/pspp.git/tree/src/libpspp/cast.h#n80
Signed-off-by: Ben Pfaff <blp@nicira.com>
Replaced all instances of Nicira Networks(, Inc) to Nicira, Inc.
Feature #10593
Signed-off-by: Raju Subramanian <rsubramanian@nicira.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
This is useful in a situation where one knows that an hmap_node is in some
hmap, but it's not certain which one, and one needs to know whether it is
in a particular one. This is not a very common case; I don't see any
potential users in the current tree, although an upcoming commit will add
one.
Signed-off-by: Ben Pfaff <blp@nicira.com>
This commit makes several library headers suitable for inclusion in C++.
It adds [extern "C"] guards and makes minor changes to fix casting and
keyword issues.
This function offers a way to iterate through an hmap in situations where
it is not safe to retain a node pointer.
Acked-by: Jesse Gross <jesse@nicira.com>
This prepares for adding a new function that deals with a "struct hmap"
moving, as opposed to a "struct hmap_node".
Since there was only a single call to this in the whole tree, and its
caller didn't have any callers of its own at all, also move this function
from hmap.h to hmap.c.
This is useful in cases where one might want to know whether an hmap_node
is actually part of an hmap, without using a separate variable to indicate
it.
Usually, the hash comparison that HMAP_FOR_EACH_WITH_HASH does is an
optimization, because comparing a hash value is usually cheaper than
comparing an entire hash map key. But for simple hash map keys, it makes
sense to just compare the key directly, because it avoids doing two
comparisons when a single simple comparison suffices. This commit adds new
functions and macros to support this simple case.
When hmap_replace() replaces one hash table node by another, it must
ensure that any nodes following the old node also follow the new node,
by copying the "next" pointer from "old" to "new".
