Re: static allocations vs. memory leaks

[Bruno Haible]

> 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