[Top][All Lists]

[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?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]