Re: memory leaks in gnulib tests (for ASAN/LINT)

[Tim Rühsen]

On 10/10/18 11:10 AM, Bernhard Voelker wrote:
> On 10/9/18 7:37 PM, Paul Eggert wrote:
>> If we want to silence these diagnostics we can either complicate the source 
>> code or complicate the debugging tool.
> 
> I'm fine with either.  Myy only concern is that code from the gnulib tests 
> might
> be taken as basis for application code.  Still, it's the repsonsibility of the
> author of such an application, yet a little "IF_LINT(free)" could be a helpful
> hint.

Right, test code is often taken as example code, especially from
newbies. And even if these people find + fix those (bugs|flaws|issues),
they will run around telling the world how bad gnulib's code base is. I
know the code base is superb thanks to truly capable and engaged
maintainers... but rumors are hard to stop. We already have enough jokes
about the "old quirky GNU neckbeards".

Given Paul's statement "Besides, debugging tools come and go...": this
means with 100 such tools we (or the people who care) would need to
write and maintain 100 exception files. This is simply not reasonable.

Instead we should think about fixing those issues at the source - just
because there is more than just one leak finder.

Staying with the current state puts endless *manual* work onto either
maintaining the exceptions/suppressions *or* onto *manual* separating
the serious from the harmless reports.

Given that people-power is becoming rarer and rarer the goal must be
automated tests+reporting without the need for maintaining these
exceptions/suppressions.

IMO the most reasonable way is to squeeze all leaks out of the (test)
source code. This is manual work just one time and makes tools, that
might come and go, happy forever (ideally, of course).

Even if no one here has time to do so, we should encourage people like
Assaf to at least report these issues (maybe there is already a list of
known issues !?). And we should encourage people to come up with
patches/suggestions and not just say "we don't want to fix those".

Regards, Tim