The fix for bug 8746 added a hashtable instance that never actually
invoked HT_FIND. This caused a warning, since we didn't mark HT_FIND
as okay-not-to-use.
scan-build recognizes that in theory there could be a numeric overflow
here.
This can't numeric overflow can't trigger IRL, since in order to fill a
hash table with more than P=402653189 buckets with a reasonable load
factor of 0.5, we'd first have P/2 malloced objects to put in it--- and
each of those would have to take take at least sizeof(void*) worth of
malloc overhead plus sizeof(void*) content, which would run you out of
address space anyway on a 32-bit system.
In digestmap_set/get benchmarks, doing unaligned access on x86
doesn't save more than a percent or so in the fast case. In the
slow case (where we cross a cache line), it could be pretty
expensive. It also makes ubsan unhappy.
clang 3.4 introduced a new by-default warning about unused static
functions, which we triggered heavily for the hashtable and map function
generating macros. We can use __attribute__ ((unused)) (thanks nickm for
the suggestion :-) ) to silence these warnings.
If you had a resolv.conf file with a nameserver line containing no
nameserver IP, we would crash. That's not terrible, but it's not
desirable.
Fixes bug 8788; bugfix on 0.1.1.23. Libevent already has this fix.
I've made an exception for cases where I'm sure that users can't
influence the inputs. This is likely to cause a slowdown somewhere,
but it's safer to siphash everything and *then* look for cases to
optimize.
This patch doesn't actually get us any _benefit_ from siphash yet,
since we don't really randomize the key at any point.
siphash is a hash function designed for producing hard-to-predict
64-bit outputs from short inputs and a 128-bit key. It's chosen for
security and speed.
See https://131002.net/siphash/ for more information on siphash.
Source: https://github.com/majek/csiphash/
This is meant to avoid conflict with the built-in log() function in
math.h. It resolves ticket 7599. First reported by dhill.
This was generated with the following perl script:
#!/usr/bin/perl -w -i -p
s/\blog\(LOG_(ERR|WARN|NOTICE|INFO|DEBUG)\s*,\s*/log_\L$1\(/g;
s/\blog\(/tor_log\(/g;
There was one place in curve25519-donna-c64 that was relying on
unaligned access and relying on little-endian values. This patch
fixes that.
I've sent Adam a pull request.
My scripts missed it because it was in eventdns.c, which was in ext,
but it _was_ using one of our identifiers. That's probably because
eventdns.c has drifted a bit since we forked it.
I'm not going to fix the other reserved identifiers in eventdns.c,
since that would make it drift even more.
