This largely copies over Spicy's `.clang-format` configuration file. The
one place where we deviate is header include order since Zeek depends on
headers being included in a certain order.
These assertions were checking for a situation that I believe can
happen legitimately: a robust iterator pointing to an index that,
after some table resizing, happens to be inside the overflow area and
hence empty. We'll now move it to the end of the table in the case.
When inserting/deleting elements, we now remove their `DictEntries`
from any robust iterators' bookkeeping. First, we don't need that
information anymore, and second the `DictEntries` contain pointers
that may become invalid.
I don't know how to write a unit test for this unfortunately because
it depends on where exactly things land in the hash table.
Btw, memory mgmt for DictEntries is pretty fragile: They contain
pointers to both memory they own (`key`) and memory they don't own
(`value`). The former type of pointers is shallow-copied on
assignment/copy-construction, meaning that there can be multiple
instances seemingly owning the same memory. That only works because
deletion is manual, and not part of standard destruction. The second
type of pointer has a similar problem, except that it's managed
externally. It's important to not end up with multiple `DictEntries`
pointing to the same value (which is actually what that iterator
bookkeeping did).
Addresses #2032.
When choosing poor/aggressive values for `table_expire_interval`,
`table_expire_delay`, and/or `table_incremental_step` that tend to
leave tables in state of constant table-expiry-iteration, the underlying
Dictionary is never allowed the chance to complete remapping operations
which re-position entries to more ideal locations (e.g. after
reallocating the table to be able to store more entries).
That situation not only leads to the Dictionary generally having a less
efficient structure, but eventually, the lack of re-positioning may
cause an insertion to calculate the new entry's
distance-from-ideal-position to be a value requiring a full 16-bits or
more (>=65535), but an entry only allows storing 16-bit distance values,
with 65535 being a sentinel value that is supposed to indicate an empty
entry. Dictionary operations may start misbehaving if that's allowed to
happen.
Previously, an assertion was triggered in debug builds upon any attempt
to insert or remove a Dictionary entry while any iteration of that
Dictionary is underway and also even in cases where Dictionary membership
was not actually modified (and thus invalidates a loop).
Now, it emits run-time warnings regardless of build-type and only when
insert/remove operations truly change the Dictionary membership. In the
context of a Zeek script causing an invalidation, the warning message
also now helps pinpoint the exact expression that causes it.
* origin/topic/timw/266-namespaces-part4: (34 commits)
Add missing namespace to usage of get_exe_path in fuzzer
Rename methods in RunState to remove 'net' from their names
Move zeek::net namespace to zeek::run_state namespace.
Move ScannedFile class and associated globals into ScannedFile.h and out of Net.h and scan.l
Rename types in ZeekList.h to be consistent with the style guide
Move NetVar from zeek to zeek::detail namespace
Remove PRI_PTR_COMPAT macros
Fix indentation of namespaced aliases
Move zeek-setup code into namespaces
Move ZeekList types to zeek namespace
Move __RegisterBif from zeek::detail::plugin to zeek::plugin::detail
Remove unimplemented zeek_magic_path/bro_magic_path method
Move all plugin classes into zeek::plugin::detail namespaces
Rename BroList.h to ZeekList.h
Move a few smaller files to zeek namespaces
Tag the end of some namespaces for consistency
Move a few of the zeek::util methods and variables to zeek::util::detail
Move zeekygen code to zeek::zeekygen::detail namespace
Mark zeek::util::pad_size as constexpr, which provides a small performance improvement
Move everything in util.h to zeek::util namespace.
...
1431186: Asserting that an unsigned value is >= 0 is pointless
1431188/1431189/1431191: Side effect of using an assignment operator in a call to ASSERT()
1431193: Dereference after null check could lead to null being used
1431195: Use of rand() replaced with random()
