From: Nick Mathewson Date: Sat, 19 Apr 2014 16:39:14 +0000 (-0400) Subject: scan-build: limit hashtable size so it always fits in SSIZE_MAX X-Git-Tag: tor-0.2.5.4-alpha~14^2~7 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=4d51dcda2fa75a3841e041ab7c3de325d73e2850;p=thirdparty%2Ftor.git scan-build: limit hashtable size so it always fits in SSIZE_MAX 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. --- diff --git a/src/ext/ht.h b/src/ext/ht.h index e76b4aa4d9..4a68673e6e 100644 --- a/src/ext/ht.h +++ b/src/ext/ht.h @@ -303,14 +303,16 @@ ht_string_hash(const char *s) #define HT_GENERATE(name, type, field, hashfn, eqfn, load, mallocfn, \ reallocfn, freefn) \ + /* Primes that aren't too far from powers of two. We stop at */ \ + /* P=402653189 because P*sizeof(void*) is less than SSIZE_MAX */ \ + /* even on a 32-bit platform. */ \ static unsigned name##_PRIMES[] = { \ 53, 97, 193, 389, \ 769, 1543, 3079, 6151, \ 12289, 24593, 49157, 98317, \ 196613, 393241, 786433, 1572869, \ 3145739, 6291469, 12582917, 25165843, \ - 50331653, 100663319, 201326611, 402653189, \ - 805306457, 1610612741 \ + 50331653, 100663319, 201326611, 402653189 \ }; \ static unsigned name##_N_PRIMES = \ (unsigned)(sizeof(name##_PRIMES)/sizeof(name##_PRIMES[0])); \