On 10/10/18 7:05 AM, Tim Rühsen wrote:
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.
Exception files are not the only way to suppress false positives. It would be better to improve the debugging tools so that they don't have the false positives in the first place. That way, we don't need to maintain unnecessarily-tricky suppression files, and we don't need to maintain unnecessarily-tricky source code either (which is even worse).
Long ago I became wary of "#ifdef lint" code because it means production code differs from the tested (or statically-analyzed) code. This wariness means that every time I look at such code there is mental overhead, which complicates and slows down maintenance. In some cases we really need to use such constructs despite their drawbacks, but this doesn't seem to be one of the cases. For example, it's reasonably safe for "#ifdef lint" code to substitute defined for undefined behavior to pacify a misguided static analyzer, but it's less safe for "#ifdef lint" to do the reverse (substitute undefined for defined behavior)
It would be better to find out some way to write the tests so that they are idiomatic and yet don't cause this limited debugging tool to report a false alarm. For tests, always doing the 'free' may be the best we can do, as Bruno is suggesting. But really, it should be incumbent on the tool makers to have better tools, and not inflict their inadequacies on all the source code out there.
