HTTPS error code 403 is now reported as:
"The https proxy refused to allow connection".
Used a switch statement for additional error codes to be explained
in the future.

If we do a replace-then-munmap, windows will never actually rewrite
the microdesc cache.

Found by wanoskarnet; bugfix on 0.2.2.6-alpha.

The new behavior is to try to rename the old file if there is one there
that we can't read.  In all likelihood, that will fail too, but at least
we tried, and at least it won't crash.

Conflicts throughout.  All resolved in favor of taking HEAD and
adding tor_mem* or fast_mem* ops as appropriate.

	src/common/Makefile.am
	src/or/circuitbuild.c
	src/or/directory.c
	src/or/dirserv.c
	src/or/dirvote.c
	src/or/networkstatus.c
	src/or/rendclient.c
	src/or/rendservice.c
	src/or/router.c
	src/or/routerlist.c
	src/or/routerparse.c
	src/or/test.c

Here I looked at the results of the automated conversion and cleaned
them up as follows:

   If there was a tor_memcmp or tor_memeq that was in fact "safe"[*] I
   changed it to a fast_memcmp or fast_memeq.

   Otherwise if there was a tor_memcmp that could turn into a
   tor_memneq or tor_memeq, I converted it.

This wants close attention.

[*] I'm erring on the side of caution here, and leaving some things
as tor_memcmp that could in my opinion use the data-dependent
fast_memcmp variant.

This commit is _exactly_ the result of

perl -i -pe 's/\bmemcmp\(/tor_memcmp\(/g' src/*/*.[ch]
perl -i -pe 's/\!\s*tor_memcmp\(/tor_memeq\(/g' src/*/*.[ch]
perl -i -pe 's/0\s*==\s*tor_memcmp\(/tor_memeq\(/g' src/*/*.[ch]
perl -i -pe 's/0\s*!=\s*tor_memcmp\(/tor_memneq\(/g' src/*/*.[ch]
git checkout src/common/di_ops.[ch]
git checkout src/or/test.c
git checkout src/common/test.h

The tor_memcmp code is by Robert Ransom, and the tor_memeq code is
by me.  Both incorporate some ideas from DJB's stuff.

Sebastian Hahn authored 13 years ago and Nick Mathewson committed 13 years ago

Found by using clang's analyzer.

Sebastian Hahn authored 13 years ago and Nick Mathewson committed 13 years ago

Issue discovered using clang's static analyzer

Sebastian Hahn authored 13 years ago and Nick Mathewson committed 13 years ago

Make that explicit by adding an assert and removing a null-check. All of
its callers currently depend on the argument being non-null anyway.
Silences a few clang complaints.

Sebastian Hahn authored 13 years ago and Nick Mathewson committed 13 years ago

This possible div by 0 warning from clang's analyzer was quite fun to
track down. Turns out the current behaviour is safe.

Sebastian Hahn authored 13 years ago and Nick Mathewson committed 13 years ago

The analyzer assumed that bootstrap_percent could be less than 0 when we
call control_event_bootstrap_problem(), which would mean we're calling
log_fn() with undefined values. The assert makes it clear this can't
happen.

Fixes bug 3106.