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.
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.
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.
In 81d69f4c2d (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.
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.
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.
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.
