> Ideally, valgrind would have a way to distinguish static memory allocations > from leaks (where by "leak" I mean an allocation that would accumulate when > the code is run repeatedly). How could such a distinction be implemented, > without multiplying the time needed to run the test by a factor of 100 or > 1000? > Possibly define a function 'static_malloc' that is equivalent to 'malloc' > in glibc, but handled differently inside valgrind?
Thinking more about it: How about a statically allocated hash table (or other complex data structure)? We don't want to complicate the code of the hash table with the option to choose a different allocator. We would need primitive functions begin/end_static_allocation() that tell valgrind to ignore the allocations between begin_static_allocation() and end_static_allocation(). And it would need to nest. Example: malloc (10); begin_static_allocation (); malloc (100); begin_static_allocation (); malloc (1000); end_static_allocation (); malloc (100); end_static_allocation (); malloc (1000000); valgrind would report two memory allocations: 10 and 1000000. Bruno
