We use a pretty specific pair of autoconf tests here to make sure
that we only add this code when:
a) a 64-bit signed multiply fails to link,
AND
b) the same 64-bit signed multiply DOES link correctly when
__mulodi4 is defined.
Closes ticket 19079.
We know there are overflows in curve25519-donna-c32, so we'll have
to have that one be fwrapv.
Only apply the asan, ubsan, and trapv options to the code that does
not need to run in constant time. Those options introduce branches
to the code they instrument.
(These introduced branches should never actually be taken, so it
might _still_ be constant time after all, but branch predictors are
complicated enough that I'm not really confident here. Let's aim for
safety.)
Closes 17983.
This makes our compilation options checks in autoconf work better on
systems that already define _FORTIFY_SOURCE.
Fixes at least one case of bug 18841; bugfix on 0.2.3.17-beta. Patch
from "trudokal".
We added these a while ago, but they do no actual good, and
cause implicit declaration warnings in some situations. Rather than
just adding stdint.h, it's easier to remove the exit() calls
as redundant.
Fixes bug 18626; bugfix from "cypherpunks"
CentOS 6 is roughly the oldest thing we care about developers still
using, and it has autoconf 2.63 / automake 1.11. These are both
older than openssl 1.0.0, so anybody who can't upgrade past those
probably can't upgrade to a modern openssl either. And since only
people building from git or editing configure.ac/Makefile.am need to
use autotools, I'm not totally enthused about keeping support for
old ones anyway.
Closes ticket 17732.
Closes ticket 18242.
The rationale here is that I like having coverage on by default in my
own working directory, but I always want assertions turned on unless
I'm doing branch coverage specifically.
We've never actually tested this support, and we should probably assume
it's broken.
To the best of my knowledge, only OpenVMS has this, and even on
OpenVMS it's a compile-time option to disable it. And I don't think
we build on openvms anyway. (Everybody else seems to be working
around the 2038 problem by using a 64-bit time_t, which won't expire
for roughly 292 billion years.)
Closes ticket 18184.
Nick Mathewson
cypherpunks
zerosion
Sebastian Hahn
Yawning Angel