The PROFILE_HASHTABLE preprocessor definition can be set at build
time and is intended to be used to enable profiling capabilities
for developers working with hash table and set data structure
profiling. This hashtable profiling functionality was added into
the code a while back and isn't currently functional, but would
ultimately be nice to have. This commit is a first step towards
getting it working.
When PROFILE_HASHTABLE is set, it causes several counters used for
collecting performance metrics to be inserted into the core hashtable
structures. When PROFILE_HASHTABLE is not set, however, these
counters are omitted, and the other members of the structure only
ever contain constant data. I'm guessing that at some point, as an
optimization in the latter case, ClamAV began declaring the hashtable
structures `const`, causing gcc (and maybe other compilers) to put
the structures in the read-only data section. Thus, the code
crashes when PROFILE_HASHTABLE is defined and the counters in the
read-only data section try to get incremented. The fix for this is
to just not mark these structures as `const` if PROFILE_HASHTABLE
is defined.
use a faster hash function
use hashset to load mdb signatures
regenerate files due to hash function change
enable hash function profiling during generation
git-svn: trunk@3589
update dependencies to rebuild on hashtab.c change
support keys with common prefix by checking match length
update due to hashtab change
git-svn: trunk@3536
* use fewer entities, browsers don't support all either.
* update to generate code for new entconv.
* no need for configure, use just a simple Makefile
(it is an internal tool)
libclamav/entconv.c, hashtab.c, htmlnorm.c:
* don't allocate memory for each entity_norm call.
* don't touch length of mmaped area (bb #785)
* update htmlnorm to use new entity_norm
git-svn: trunk@3515
Include new entitylist generated using contrib/entitynorm/generate_entitylist (bb #391)
Fix bug in growing hash tables (must use hash on new table)
git-svn: trunk@2920
micasnyd