This can be used to get less cryptic error/warnings from GCC when
dealing with something typesafe container related.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
The previous change to assume() did address the coverity warning about
one direction of the shift in HASH_KEY, let's constrain the other in
HASH_SIZE as well.
To be fair, the hash table *will* break at 1G entries, but at that point
we have other problems RAM-wise. (Could bump the thing to 64-bit, but
then we need better item hash functions too on every single user.)
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
This is noted in doc/developer/lists.rst, but judging by the previous
commit that's not where people look for this thing. Let's try a comment
in the header file.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
This reverts commit 72eae2c3cb.
`frr_each_const(X, ...)` is not needed since it is the same as
`frr_each(X_const, ...)`.
The fact that it wasn't properly set up for clang-format, and that then
work-arounded with "clang-format off" is all the more reason to not do
this.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
The typesafe hash _member() didn't check tabshift/count before
proceeding to look at the hash table, leading it to dereference a NULL
pointer when the hash table is in fact empty.
Test case added to tests/lib/test_typelist.
Note this function is not currently used anywhere. Only lib/cspf.c uses
_member(), but it does so on a RB-tree rather than a hash.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Looking at the coverity report, it complains that tabshift could be
zero, resulting in a uint32_t shifted by 33 (which is undefined.)
As I was confused by the "+ 1", in addition to the SA assume(), leave
some breadcumbs for next time this comes up.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
The typesafe hash data structure enforces items to be unique, but their
hash values may still collide. To this extent, when two items have the
same hash value, the compare function is called to see if it returns 0
(aka "equal").
While the _find() function handles this correctly, the _add() function
mistakenly only checked the first item with a colliding hash value for
equality, and if it was inequal proceeded to add the new item. There
may however be additional items with the same hash value collision, one
of which could still compare as equal. In that case, _add() would
mistakenly add the new element, failing to notice the already added
item. Breakage ensues.
Fix by looking for an equal element among *all* existing items with the
same hash value, not just the first.
Signed-off-by: Francois Dumontet <francois.dumontet@6wind.com>
[DL: rewrote commit message, fixed whitespace/formatting]
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Literally 4 minutes after hitting merge on Mark's previous fix for this
I remembered we have an `assume()` macro in compiler.h which seems like
the right tool for this.
(... and if I'm touching it, I might as well add a little text
explaining what's going on here.)
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
RB-tree and double-linked-list easily support backwards iteration, and
an use case seems to have popped up. Let's make it accessible.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
`assert.h` -> `xref.h` -> `typesafe.h` -> `assert.h`
Might be possible to do this more cleanly some way, but that way is not
obvious, so here's the "simple & dumb" approach.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
*_anywhere(item) returns whether an item is on _any_ container. Only
available for unsorted containers for now.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Using a non-NULL sentinel allows distinguishing between "end of list"
and "item not on any list". It's a compare either way, just the value
is different.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
This provides a "is this item on this list" check, which may or may not
be faster than using *_find() for the same purpose. (If the container
has no faster way of doing it, it falls back to using *_find().)
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Some of the typesafe containers didn't null out their innards of items
after an item was deleted or popped off the container. This is both a
bit unsafe as well as hinders the upcoming _member() from working
efficiently.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Based on work originally by Mark Stapp <mjs@voltanet.io>.
Make it possible to iterate the typesafe lists in a const
context, as well as find items from them.
Signed-off-by: Mark Stapp <mjs@voltanet.io>
[above signoff was for the original version before modification]
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
The new list api did not implement the `*_del` endpoint as
it was described in the docs here:
http://docs.frrouting.org/projects/dev-guide/en/latest/lists.html#c.Z_del
This patch implements the endpoints to return the object deleted if
found, otherwise NULL for all but the atomic lists.
The atomic list `*_del` code is marked as TODO and will remain undefined
for now.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
This is necessary to avoid a name collision with std::for_each
from C++.
Fixes the compilation of the gRPC northbound module.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
This is an 8-ary heap (cacheline optimized.) It works as a semi-sorted
kind of middle ground between unsorted and sorted datastructures; pop()
always returns the lowest item but ordering is only loosely enforced.
Signed-off-by: David Lamparter <equinox@diac24.net>
Turns out we need one of these. Same API as DECLARE_LIST, but deleting
random items is much faster.
Signed-off-by: David Lamparter <equinox@diac24.net>
The skiplist code was previously falling back to the del() code path for
a pop() on a skiplist. This is unneeded complexity, a pop() can be done
more efficiently.
Signed-off-by: David Lamparter <equinox@diac24.net>
The head of a list should not change for find functions. Probably
are others that should be considered but these changes can come
in as needed I believe.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The head of a list should not change for find functions. Probably
are others that should be considered but these changes can come
in as needed I believe.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Typesafe red-black tree, built out of the OpenBSD implementation and the
macro soup layered on top. API compatible with skiplists & simple
lists.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
By the power of the C preprocessor, these macros provide type-safe
warppers for simple lists, skiplists and hash tables. Also, by changing
the instantiation macro, it is easily possible to switch between
algorithms; the code itself does not need to be changed since the API
is identical across all algorithms.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
