Re: fstrcmp: memory is not reclaimed on exit

[Bruno Haible]

Paul Eggert wrote:
> it's merely choosing a point in a design space that involves simplicity, 
> efficiency, correctness, testability, etc. and where there are several 
> reasonable choices.

Right. In the case of fstrcmp, the bison tests use 'valgrind -q'. Akim could
use 'valgrind -q --leak-check=no'; then there would be no need to add a
cleanup to fstrcmp.c. However, I think that 'valgrind -q --leak-check=no'
would be a lot less useful for the day-to-day maintenance of bison than
'valgrind -q'. Therefore I think Akim made a reasonable choice here -
although it differs from the equally reasonable broader guideline in the GCS.

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?

Bruno