MSVC warns if you declare a function as having a "int foo" argument
and then implement it with a "const int foo" argument, even though
the latter "const" is not a part of the function's interface.
Instead, allow packagers to put a 'TOR_BUILD_TAG' field in the
server descriptor to indicate a platform-specific value, if they
need to. (According to weasel, this was his use for the git- tag
previously.)
This is part of 2988
For uname-based detection, we now give only the OS name (e.g.,
"Darwin", "Linux".) For Windows, we give only the Operating System
name as inferred from dw(Major|Minor)version, (e.g., "Windows XP",
"Windows 7"), and whether the VER_NT_SERVER flag is set.
For ticket 2988.
We were doing an O(n) strlen in router_get_extrainfo_hash() for
every one we tried to parse. Instead, have
router_get_extrainfo_hash() take the length of the extrainfo as an
argument, so that when it's called from
extrainfo_parse_from_string(), it doesn't do a strlen() over the
whole pile of extrainfos.
Now that the pt code logs mp->argv[0] all over the place, we need to
be sure to set up mp->argv in our tests.
Bugfix on e603692adc, not in any released version.
If the authorities agreed on a sufficiently bad bwweightscale value
(<=0 or == INT32_MAX), the bandwidth algorithm could make the voters
assert while computing the consensus.
Fix for bug5786; bugfix on 0.2.2.17-alpha
The underlying strtoX functions handle overflow by saturating and
setting errno to ERANGE. If the min/max arguments to the
tor_parse_* functions are equal to the minimum/maximum of the
underlying type, then with the old approach, we wouldn't treat a
too-large value as genuinely broken.
Found this while looking at bug 5786; bugfix on 19da1f36 (in Tor
0.0.9), which introduced these functions.
(Note: It makes sense to use tor-gencert on Windows for testing
purposes only. If you are a directory authority operator, and you
are contemplating running tor-gencert on a Windows box in an actual
production environment, you are probably making a mistake.)
