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