Re: reclaiming memory before exit, take 2

[Paul Eggert]

Thanks for the summary.

On 5/16/20 7:04 AM, Bruno Haible wrote:

> Paul writes in [1]:
>> In any event, it seems to me to be a deficiency in the detection if it
>> reports allocated memory which is still referenced to by global
>> variables, or even static variables, as memory leaks.
> 
> On the contrary, reporting leaks through global and static variables is
> a feature. *Hiding* them, which is what the tools do by default, is a
> *misfeature*.

This depends on what sort of leaks you're looking for. I agree that these are
very often leaks, and that it generally makes sense to look for them. However, I
don't think we always need to worry about these leaks just before program exit,
since they are not a performance problem there and introducing 'free' there both
complicates and slows the program.

This underlying issue dates back at least to the 1960s, by the way. PL/I has
based pointers, and you needn't free the objects they point to if you delete the
containing area ("area" is PL/I-ese for "heap").
> The QA automation needs to rely on the suppression files created by the
> developers, since it's not a QA engineer's job to evaluate whether a
> particular memory leak is serious or not.

This division of labor is not universal. In many shops, QA engineers are more
involved in determining the seriousness of bugs, and they can maintain
suppression files.