[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: fstrcmp: memory is not reclaimed on exit
From: |
Bruno Haible |
Subject: |
Re: fstrcmp: memory is not reclaimed on exit |
Date: |
Sun, 16 Feb 2020 23:24:40 +0100 |
User-agent: |
KMail/5.1.3 (Linux/4.4.0-171-generic; KDE/5.18.0; x86_64; ; ) |
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