Generating functions is ugly. Ideally astyle wouldn't ask us to write 4
lines of code where 1 would be more readable, but such is life (until we
move to clang-format).
Needed for the build afterwards.
Also added the cflite Dockerfile to automatic CI builds so changes to it
are checked in pull requests.
Also fixed the tokstyle docker image. It needs clang instead of gcc now.
The idea here is to have a `Network` object that contains functions for
network operations and an optional userdata object that can manage those
network operations. This allows e.g. a fuzzer to replace the network
functions with no-ops or fuzzer inputs, reducing the need for `#ifdef`s.
This is very slow, around 20 minutes, which seriously slows down
velocity for little gain. MSAN runs on unit tests and 1 auto test, so
we'll catch increasingly many valgrind-ish bugs that way in one of the
1-5-minute builds.
Cimple cannot actually find these without also causing false positives,
but I found them with cimple before removing the code causing false
positives again.
We were leaving a self_connection_status callback attached to tox1 while
reloading tox2 and 3, the only other toxes in the network. This lead to
tox1 occasionally going offline, triggering the "Tox went offline"
assert and failing the test.
I don't know if this will actually work, or how many of these "fixes" I
need to get msan to be happy on CI. For me locally, it all works fine.
On CI, for some reason it's not fine even though I run in the exact same
docker image as CI.
This happens when shutting down a toxav session when it still has some
packets in its internal queue. It's not a serious leak and happens very
rarely (1 in 300 runs of the toxav_many_test), but it can happen and
long-running tox instances that start and end calls a lot would
eventually discover this.
Almost nothing used these. The one thing that did only does it to get a
`Mono_Time` object. We should probably get that from elsewhere, but for
now the refactoring is just this simple move.
For coverity, which continues to think we're overrunning buffers when
at this point it's easy to prove we're not. Here would be the corrected
coverity finding:
6. Condition packet_length <= 105 /* 1 + 32 * 2 + 24 + 16 */, taking false branch.
7. Condition packet_length > 1024, taking false branch.
Now packet_length must be > 105 and <= 1024.
12. Condition len1 == packet_length - (89 /* 1 + 32 * 2 + 24 */) - 16, taking true branch.
len1 must be > 0 (105 - 89 - 16) and <= 919 (1024 - 89 - 16).
14. decr: Decrementing len1. The value of len1 is now between 0 and 919 (inclusive).
This is where coverity goes wrong: it thinks len1 could be up to 2147483629.
15. buffer access should be OK. Coverity thinks it's not.
Nothing very noteworthy, I just came across this and made it slightly
more readable.
I'm not making this function `bool` right now because it's used in NGC
and that will break.
