mir/ovs
2
0
Fork 0
mirror of https://github.com/openvswitch/ovs synced 2025-08-23 10:28:00 +00:00
Code Issues Releases Wiki Activity
ovs/lib/hmapx.h

87 lines
3.2 KiB
C
Raw Normal View History

hmapx: New data structure.
2011-04-07 17:10:48 -07:00
/*
hmap: Add extra build-time iteration checks for types derived from hmap. Some of our data structures derived from hmap use the same member names. This means it's possible to confuse them in iteration, e.g. to iterate a shash with SIMAP_FOR_EACH. Of course this will crash at runtime, but it seems even better to catch it at compile time. An alternative would be to use unique member names, e.g. shash_map and simap_map instead of just map. I like short names, though. It's kind of nasty that we need support from the hmap code to do this. An alternative would be to insert the build assertions as statements before the for loop. But that would cause nasty surprises if someone forgets the {} around a block of statements; even though the OVS coding style requires them in all cases, I suspect that programmers doing debugging, etc. tend to omit them sometimes. It's not actually necessary to have multiple variants of these macros, e.g. one can write a C99-compliant HMAP_FOR_EACH that accepts 3 or 4 or more arguments. But such a macro is harder to read, so I don't know whether this is a good tradeoff. Signed-off-by: Ben Pfaff <blp@ovn.org> Acked-by: Andy Zhou <azhou@ovn.org>
2016-02-08 16:52:45 -08:00
* Copyright (c) 2011, 2016 Nicira, Inc.
hmapx: New data structure.
2011-04-07 17:10:48 -07:00
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at:
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
#ifndef HMAPX_H
#define HMAPX_H
json: Move from lib to include/openvswitch. To easily allow both in- and out-of-tree building of the Python wrapper for the OVS JSON parser (e.g. w/ pip), move json.h to include/openvswitch. This also requires moving lib/{hmap,shash}.h. Both hmap.h and shash.h were #include-ing "util.h" even though the headers themselves did not use anything from there, but rather from include/openvswitch/util.h. Fixing that required including util.h in several C files mostly due to OVS_NOT_REACHED and things like xmalloc. Signed-off-by: Terry Wilson <twilson@redhat.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
2016-07-12 16:37:34 -05:00
#include "openvswitch/hmap.h"
hmapx: New data structure.
2011-04-07 17:10:48 -07:00
struct hmapx_node {
struct hmap_node hmap_node;
void *data;
};
/* A set of "void *" pointers. */
struct hmapx {
struct hmap map;
};
#define HMAPX_INITIALIZER(HMAPX) { HMAP_INITIALIZER(&(HMAPX)->map) }
/* Basics. */
void hmapx_init(struct hmapx *);
void hmapx_destroy(struct hmapx *);
void hmapx_clone(struct hmapx *, const struct hmapx *);
void hmapx_swap(struct hmapx *, struct hmapx *);
void hmapx_moved(struct hmapx *);
/* Count. */
bool hmapx_is_empty(const struct hmapx *);
size_t hmapx_count(const struct hmapx *);
/* Insertion. */
struct hmapx_node *hmapx_add(struct hmapx *, void *);
void hmapx_add_assert(struct hmapx *, void *);
/* Deletion. */
void hmapx_clear(struct hmapx *);
void hmapx_delete(struct hmapx *, struct hmapx_node *);
bool hmapx_find_and_delete(struct hmapx *, const void *);
void hmapx_find_and_delete_assert(struct hmapx *, const void *);
/* Search. */
struct hmapx_node *hmapx_find(const struct hmapx *, const void *);
bool hmapx_contains(const struct hmapx *, const void *);
bool hmapx_equals(const struct hmapx *, const struct hmapx *);
/* Iteration. */
/* Iterates through every hmapx_node in HMAPX. */
hmap: Add extra build-time iteration checks for types derived from hmap. Some of our data structures derived from hmap use the same member names. This means it's possible to confuse them in iteration, e.g. to iterate a shash with SIMAP_FOR_EACH. Of course this will crash at runtime, but it seems even better to catch it at compile time. An alternative would be to use unique member names, e.g. shash_map and simap_map instead of just map. I like short names, though. It's kind of nasty that we need support from the hmap code to do this. An alternative would be to insert the build assertions as statements before the for loop. But that would cause nasty surprises if someone forgets the {} around a block of statements; even though the OVS coding style requires them in all cases, I suspect that programmers doing debugging, etc. tend to omit them sometimes. It's not actually necessary to have multiple variants of these macros, e.g. one can write a C99-compliant HMAP_FOR_EACH that accepts 3 or 4 or more arguments. But such a macro is harder to read, so I don't know whether this is a good tradeoff. Signed-off-by: Ben Pfaff <blp@ovn.org> Acked-by: Andy Zhou <azhou@ovn.org>
2016-02-08 16:52:45 -08:00
#define HMAPX_FOR_EACH(NODE, HMAPX) \
HMAP_FOR_EACH_INIT(NODE, hmap_node, &(HMAPX)->map, \
BUILD_ASSERT_TYPE(NODE, struct hmapx_node *), \
BUILD_ASSERT_TYPE(HMAPX, struct hmapx *))
hmapx: New data structure.
2011-04-07 17:10:48 -07:00
/* Safe when NODE may be freed (not needed when NODE may be removed from the
* hash map but its members remain accessible and intact). */
hmap: use short version of safe loops if possible. Using SHORT version of the *_SAFE loops makes the code cleaner and less error prone. So, use the SHORT version and remove the extra variable when possible for hmap and all its derived types. In order to be able to use both long and short versions without changing the name of the macro for all the clients, overload the existing name and select the appropriate version depending on the number of arguments. Acked-by: Dumitru Ceara <dceara@redhat.com> Acked-by: Eelco Chaudron <echaudro@redhat.com> Signed-off-by: Adrian Moreno <amorenoz@redhat.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2022-03-23 12:56:17 +01:00
#define HMAPX_FOR_EACH_SAFE_SHORT(NODE, HMAPX) \
HMAP_FOR_EACH_SAFE_SHORT_INIT (NODE, hmap_node, &(HMAPX)->map, \
BUILD_ASSERT_TYPE(NODE, struct hmapx_node *), \
BUILD_ASSERT_TYPE(HMAPX, struct hmapx *))
#define HMAPX_FOR_EACH_SAFE_LONG(NODE, NEXT, HMAPX) \
HMAP_FOR_EACH_SAFE_LONG_INIT (NODE, NEXT, hmap_node, &(HMAPX)->map, \
hmap: Add extra build-time iteration checks for types derived from hmap. Some of our data structures derived from hmap use the same member names. This means it's possible to confuse them in iteration, e.g. to iterate a shash with SIMAP_FOR_EACH. Of course this will crash at runtime, but it seems even better to catch it at compile time. An alternative would be to use unique member names, e.g. shash_map and simap_map instead of just map. I like short names, though. It's kind of nasty that we need support from the hmap code to do this. An alternative would be to insert the build assertions as statements before the for loop. But that would cause nasty surprises if someone forgets the {} around a block of statements; even though the OVS coding style requires them in all cases, I suspect that programmers doing debugging, etc. tend to omit them sometimes. It's not actually necessary to have multiple variants of these macros, e.g. one can write a C99-compliant HMAP_FOR_EACH that accepts 3 or 4 or more arguments. But such a macro is harder to read, so I don't know whether this is a good tradeoff. Signed-off-by: Ben Pfaff <blp@ovn.org> Acked-by: Andy Zhou <azhou@ovn.org>
2016-02-08 16:52:45 -08:00
BUILD_ASSERT_TYPE(NODE, struct hmapx_node *), \
BUILD_ASSERT_TYPE(NEXT, struct hmapx_node *), \
BUILD_ASSERT_TYPE(HMAPX, struct hmapx *))
hmapx: New data structure.
2011-04-07 17:10:48 -07:00
hmap: use short version of safe loops if possible. Using SHORT version of the *_SAFE loops makes the code cleaner and less error prone. So, use the SHORT version and remove the extra variable when possible for hmap and all its derived types. In order to be able to use both long and short versions without changing the name of the macro for all the clients, overload the existing name and select the appropriate version depending on the number of arguments. Acked-by: Dumitru Ceara <dceara@redhat.com> Acked-by: Eelco Chaudron <echaudro@redhat.com> Signed-off-by: Adrian Moreno <amorenoz@redhat.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2022-03-23 12:56:17 +01:00
#define HMAPX_FOR_EACH_SAFE(...) \
OVERLOAD_SAFE_MACRO(HMAPX_FOR_EACH_SAFE_LONG, \
HMAPX_FOR_EACH_SAFE_SHORT, \
3, __VA_ARGS__)
hmapx: New data structure.
2011-04-07 17:10:48 -07:00
#endif /* hmapx.h */
Reference in New Issue Copy Permalink