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
