We previously used FILENAME_PRIVATE identifiers mostly for
identifiers exposed only to the unit tests... but also for
identifiers exposed to the benchmarker, and sometimes for
identifiers exposed to a similar module, and occasionally for no
really good reason at all.

Now, we use FILENAME_PRIVATE identifiers for identifiers shared by
Tor and the unit tests.  They should be defined static when we
aren't building the unit test, and globally visible otherwise. (The
STATIC macro will keep us honest here.)

For identifiers used only by the unit tests and never by Tor at all,
on the other hand, we wrap them in #ifdef TOR_UNIT_TESTS.

This is not the motivating use case for the split test/non-test
build system; it's just a test example to see how it works, and to
take a chance to clean up the code a little.

This is mainly a matter of automake trickery: we build each static
library in two versions now: one with the TOR_UNIT_TESTS macro
defined, and one without.  When TOR_UNIT_TESTS is defined, we can
enable mocking and expose more functions. When it's not defined, we
can lock the binary down more.

The alternatives would be to have alternate build modes: a "testing
configuration" for building the libraries with test support, and a
"production configuration" for building them without.  I don't favor
that approach, since I think it would mean more people runnning
binaries build for testing, or more people not running unit tests.

 Fix a bug in the voting algorithm that could yield incorrect results
 when a non-naming authority declared too many flags. Fixes bug 9200;
 bugfix on 0.2.0.3-alpha.

Found by coverity scan.

Ticket 9147.

(This caused a crash that was reported as bug 9122, but the underlying
behavior has been wrong for a while.)

Fix on 0.2.3.9-alpha.

Fixes bug 9090; bug not in any released Tor.

Spotted by Coverity Scan. Not in any released Tor.

Conflicts:
	src/or/config.c
	src/or/relay.c

This implements "algorithm 1" from my discussion of bug #9072: on OOM,
find the circuits with the longest queues, and kill them.  It's also a
fix for #9063 -- without the side-effects of bug #9072.

The memory bounds aren't perfect here, and you need to be sure to
allow some slack for the rest of Tor's usage.

This isn't a perfect fix; the rest of the solutions I describe on
codeable.

That security measure costs more than it gives.
So, keep your PATH sane and we can run this script on more than
one system.

In my #7912 fix, there wasn't any code to remove entries from the
(channel, circuit ID)->circuit map corresponding to queued but un-sent
DESTROYs.

Spotted by skruffy. Fixes bug 9082; bug not in any released Tor.

Fixes bug 9002; bugfix on 0.1.1.11-alpha (which introduced guard
nodes), or on 0.0.6pre1 (which introduced hidden services).

dana koch authored 11 years ago and Nick Mathewson committed 11 years ago

This lets us have the possibility of fine-tuning the check in the tor_sscanf test cases at a later date.