The documentation for this function says that the smartlist can
contain NULLs, but the code only handled NULLs if they were at the
start of the list.
We didn't notice this for a long time, because when Tor is run
normally, the sequence of msg_id_t is densely packed, and so this
list (mapping msg_id_t to channel_id_t) contains no NULL elements.
We could only run into this bug:
* when Tor was running in embedded mode, and starting more than once.
* when Tor ran first with more pubsub messages enabled, and then
later with fewer.
* When the second run (the one with fewer enabled pubsub messages)
had at least some messages enabled, and those messages were not
the ones with numerically highest msg_id_t values.
Fixes bug 31898; bugfix on 47de9c7b0a
in 0.4.1.1-alpha.
There is a bad design choice in two of our configuration types,
where the empty string encodes a value that is not the same as the
default value. This design choice, plus an implementation mistake,
meant that config_dup() did not preserve the value of routerset_t,
and thereby caused bug #31495.
This comment-only patch documents the two types with the problem,
and suggests that implementors try to avoid it in the future.
Closes ticket 31907.
This test failure happened due to a signed/unsigned integer
comparison.
This bug occurred on SunOS, it may also occur on other systems that
use signed char as the default. (And cast 1-byte integer constants
to an unsigned integer.)
Fixes bug 31897; bugfix on 0.4.1.1-alpha.
Our line limit is 80 characters, assuming that there is a single
terminating newline character that counts towards the limit. On
Windows, this might go as high as 81 characters, if we count CRLF as
two characters.
This change should reduce the number of cases where we say
"/* !(!defined(foo)) */" .
This only does cases where we can use a regex to make sure that the
simplification is guaranteed to be correct. Full boolean
simplification would require this script to parse C, and nobody
wants that.
The log mutex is dynamically initialized, guarded by log_mutex_initialized.
We don't want to destroy it, because after it is destroyed, we won't see
any more logs.
If tor is re-initialized, log_mutex_initialized will still be 1. So we
won't trigger any undefined behaviour by trying to re-initialize the
log mutex.
Part of 31736, but committed in this branch to avoid merge conflicts.
cb_buf_mutex is statically initialised, so we can not destroy it when
we are shutting down the err subsystem. If we destroy it, and then
re-initialise tor, all our backtraces will fail.
Part of 31736, but committed in this branch to avoid merge conflicts.
