GCC's interpretation of the C99 aliasing rules, to be charitable,
creates a dialect of C intended for a better programmers than I am
certain of my ability to be in all times. I just spent 2 hours
tracking down a platform-hyperspecific libevent bug that turned out to
be because of this, and darned if I ever want to do *that* again.
One of Linus's recent rants will give you a picture of why GCC's
behavior here can lead to fun surprises in your binaries:
http://lwn.net/Articles/316126/
svn:r18351
merge the 'bridge relay' section into the 'main relay'
section, so people stop getting confused about whether they
should fill out both sections (they shouldn't).
svn:r18348
This resolves bug 526, wherein we would crash if the following
events occurred in this order:
A: We're an OR, and one of our nameservers goes down.
B: We launch a probe to it to see if it's up again. (We do this hourly
in steady-state.)
C: Before the probe finishes, we reconfigure our nameservers,
usually because we got a SIGHUP and the resolve.conf file changed.
D: The probe reply comes back, or times out. (There is a five-second
window for this, after B has happens).
IOW, if one of our nameservers is down and our nameserver
configuration has changed, there were 5 seconds per hour where HUPing
the server was unsafe.
Bugfix on 0.1.2.1-alpha. Too obscure to backport.
svn:r18306
This fixes the last known case of bug 891, which could happen if two
hosts, A and B, disagree about how long a circuit has been open,
because of clock drift of some kind. Host A would then mark the
connection as is_bad_for_new_circs when it got too old and open a new
connection. In between when B receives a NETINFO cell on the new
conn, and when B receives a conn cell on the new circuit, the new
circuit will seem worse to B than the old one, and so B will mark it
as is_bad_for_new_circs in the second or third loop of
connection_or_group_set_badness().
Bugfix on 0.1.1.13-alpha. Bug found by rovv.
Not a backport candidate: the bug is too obscure and the fix too tricky.
svn:r18303
crypto_global_init gets called. Also have it be crypto_global_init
that calls crypto_seed_rng, so we are not dependent on OpenSSL's
RAND_poll in these fiddly cases.
Should fix bug 907. Bugfix on 0.0.9pre6. Backport candidate.
svn:r18210
base64 from coreutils is really picky about the number of equation
marks (=) that end a base64 encoded string. Unfortunately Tor doesn't
believe they are important at all so it cuts them all off all the time.
For perl purposes we just added a good measure of = and were happy about
it. For base64 we now need to add the proper number of equation marks.
It turns out that number is 1 for the length of strings we process.
svn:r18170
