| Commit message (Collapse) | Author | Age |
|---|
| | |
|
| |\
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
src/common/include.am
Conflict was from adding testsupport.h near where sandbox.h had
already been added.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
If you pass the --enable-coverage flag on the command line, we build
our testing binaries with appropriate options eo enable coverage
testing. We also build a "tor-cov" binary that has coverage enabled,
for integration tests.
On recent OSX versions, test coverage only works with clang, not gcc.
So we warn about that.
Also add a contrib/coverage script to actually run gcov with the
appropriate options to generate useful .gcov files. (Thanks to
automake, the .o files will not have the names that gcov expects to
find.)
Also, remove generated gcda and gcno files on clean.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |\ \
| |/
|/| |
|
| | |
| |
| |
| |
| | |
It's controlled by the new Sandbox argument. Right now, it's rather
coarse-grained, it's Linux-only, and it may break some features.
|
| |/
|
|
|
|
| |
This is a bashism; on systems where sh is not bash (eg., non-Linux, or
Ubuntu using dash), this breaks with a syntax error. This also doesn't
work properly in bash: only the first item is iterated on.
|
| | |
|
| |
|
|
| |
See #6506
|
| |
|
|
|
|
|
|
|
|
| |
If USE_ASCIIDOC is enabled but asciidoc isn't present and manpages
aren't already generated, it'll throw a warning during configure.
Works with the current git / tarball split.
Caveat: regular_mans are listed in the configure.ac
See #6506
|
| |\ |
|
| | |
| |
| |
| |
| |
| | |
Clang 3.2 does constant-folding and variable substitution to determine
that the program is equivalent to "return 1". Splitting the 128-bit
math into a new function seems sufficient to fix this.
|
| | |
| |
| |
| |
| |
| |
| | |
Dumb bug 1: == has higher precedence than &.
Dumb bug 2: the main() function in an AC_RUN_IFELSE test is expected
to return 0 on success, not 1.
|
| |\| |
|
| | |\
| | |
| | |
| | | |
(This is the part of the Bug 8042 patch that warns about unsigned time_t)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Inspired by #8042.
As far as I know, OpenVMS is the only place you're likely to hit an
unsigned time_t these days, and Tor's VMS support
is... lacking. Still worth letting people know about it, though.
|
| |\| | |
|
| | | |
| | |
| | |
| | | |
Resolves the user experience part of #8014.
|
| |\| | |
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In 81d69f4c2d8a451 (0.2.21-alpha) we added a compile-time check for
a (totally broken) signed size_t. In 0e597471af (not yet released)
I switched to a better configure-time check, which stored its output
in a different variable. I didn't change the code which looked at
the output, however.
This bug is not in any released version of Tor, and would not affect
anybody with a working Tor.
|
| |\ \ |
|
| | | | |
|
| | | | |
|
| | |/
|/| |
|
| | |
| |
| |
| | |
Fixes bug 7727; fix on 0.2.4.10-alpha.
|
| | |
| |
| |
| | |
This beats our old implementation, which wouldn't work when cross-compiling
|
| | | |
|
| | | |
|
| |/
|
|
|
|
|
| |
This is allowed by the C statndard, which permits you to represent
doubles any way you like, but in practice we have some code that
assumes that memset() clears doubles in structs. Noticed as part of
7802 review; see 8081 for more info.
|
| |
|
|
| |
Fix for bug 7972
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |\
| |
| |
| |
| |
| |
| | |
Conflicts:
src/or/cpuworker.c
src/or/or.h
src/test/bench.c
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We want to use donna-c64 when we have a GCC with support for
64x64->uint128_t multiplying. If not, we want to use libnacl if we
can, unless it's giving us the unsafe "ref" implementation. And if
that isn't going to work, we'd like to use the
portable-and-safe-but-slow 32-bit "donna" implementation.
We might need more library searching for the correct libnacl,
especially once the next libnacl release is out -- it's likely to have
bunches of better curve25519 implementations.
I also define a set of curve25519 wrapper functions, though it really
shouldn't be necessary.
We should eventually make the -donna*.c files get build with
-fomit-frame-pointer, since that can make a difference.
|
| | | |
|
| | | |
|
| |\ \
| |/
|/|
| |
| | |
Conflicts:
src/or/dns.c
|
| | |
| |
| |
| | |
Patch from yayooo for bug 7260, forward-ported to 0.2.4.
|
| | | |
|
| |/ |
|
| | |
|
| |
|
|
| |
(For real this time. It turns out that 4 and 5 are different numbers.)
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Bitrig is an openbsd fork. Patch from dhill. Ticket 6982.
|
| | |
|