I think that the trailing __ got added in false analogy to
HAVE_MACRO__func__, HAVE_MACRO__FUNC__, and HAVE_MACRO__FUNCTION__.
But those macros actually indicate the presence of __func__,
__FUNC__, and __FUNCTION__ respectively.  The __ at the end of
HAVE_EXTERN_ENVIRON_DECLARED would only be appropriate if the
environ were declared__, whatever that means.

(As a side-note, HAVE_MACRO__func__ and so on should probably be
renamed HAVE_MACRO___func__ and so on.  But that can wait.)

This is an identifier renaming only.

We'd had our configure.in test include unistd.h unconditionally,
which would fail on Windows/mingw, even though environ _was_
declared there.  Fix for 5704; bugfix on 0.2.3.13-alpha.

Thanks to Erinn for finding this and rransom for figuring out the
problem.

They boil down to:
 - MS_WINDOWS is dead and replaced with _WIN32, but we let a few
   instances creep in when we merged Esteban's tests.
 - Capitalizing windows header names confuses mingw.
 - #ifdef 0 ain't C.
 - One unit test wasn't compiled on windows, but was being listed
   anyway.
 - One unit test was checking for the wrong value.

Gisle Vanem found and fixed the latter 3 issues.

Arturo Filastò authored 13 years ago and Nick Mathewson committed 12 years ago

Fixes bug #4528 "read_to_buf_tls(): Inconsistency in code".

This check was added back in 0.1.0.3-rc, but somehow we forgot to
leave it in when we refactored read_to_buf_tls in 0.1.0.5-rc.

(patch by Arturo; commit message and changes file by nickm)

fixes bug 5623.

Instead of checking for 'rejected' and calling everything else okay,
let's check for 'outdated' and call everythign else a problem.  This
way we don't risk missing future errors so much.

When logging a message that _looks_ like an error message at info, we
should mention that it isn't really a problem.

Anthony G. Basile authored 13 years ago and Nick Mathewson committed 12 years ago

The bump from miniupnpc-1.5 to 1.6 changes the definition of
two functions used by tor-fw-helper-upnp.c, upnpDiscover() and
UPNP_AddPortMapping().  This patch addresses this and adds a
check in configure.in for backwards compatibility.

Thanks to Nickolay Kolchin-Semyonov for some hints.

X-Tor-Bug-URL: https://trac.torproject.org/projects/tor/ticket/5434
X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=376621


Signed-off-by: Anthony G. Basile <blueness@gentoo.org>

Robert Ransom authored 12 years ago and Nick Mathewson committed 12 years ago

Previously, we would reset it at the drop of a hat -- every time a second
passes without any of the intro-point circs already launched for the
service failing.

Fixes bug 4607.

In general, whenever we can, we should be doing
  base64_decode(buf, sizeof(buf), s, strlen(s)),
and not
  base_64_decode(buf, expr1, s, expr2)
where we hope that expr1 is a good name for the size of buf and expr2
is a good formula for the length of the base64 expression in s.

Fix for 5647; bugfix on 0.2.1.5-alpha.

Conflicts:
	src/or/rendservice.c

Conflicts were due to new NON_ANONYMOUS_MODE_ENABLED tor2web code; I
think I resolved them correctly.

George Kadianakis authored 12 years ago and Nick Mathewson committed 12 years ago

(Cherry-picked from 6ba13e4 by nickm)

Fixes coverity CID 508: coverity scan doesn't like checking a
variable for non-NULL after it has been definitely dereferenced.

This should take us back down to zero coverity issues.

Fix for 5635; fix on 0.2.2.26-beta, where caches stopped fetching this
information.

* Remove the ugly if statement.
* constify 'bridge_info_t' in SMARTLIST_FOREACH_BEGIN.