On Mon, Dec 19, 2016 at 01:06:35PM -0500, Jeff Darcy wrote: > Before we get to automation, shouldn't we have a discussion about what > "defects" we should filter out? For example, we already have a problem > with compilers spitting out warnings about unused variables in generated > code, and then promoting those warnings to errors. Fixing those is more > trouble than it's worth. Static analyzers are going to produce even > more reports of Things That Don't Really Matter, along with a few about > Actual Serious Problems. It's a characteristic of the genre. If we > don't make any explicit decisions about priorities, it will actually > take us longer to fix all of the null-pointer errors and array overflows > and memory leaks as people wade through a sea of lesser defects. This is a legitimate cause for worry and I don't want to have us overwhelmed with tools that give us false errors. We have several options here: 1. We can write our test script in such a way that we write config file in-tree for cpp check with a list of files and/or paths to exclude for cppcheck. 2. We write a list of known failures that are known false positives, that also go in the tree, so you can modify them if your commit adds a false positive. From my point of view, this is slightly more work, but elimintes the overhead of compiling twice. Does this solve the concerns that we have? We've been running static analysis tools for quite some time without paying too much attention to it. My primary cause for action is the warning from distributions[1] to fix some of the errors from cppcheck. It's also a tiny enough target that we can use to plan how we'll approach other static analysis tools. Happy to have more criticisms that we can address. [1]: https://bugs.launchpad.net/ubuntu/+source/glusterfs/+bug/1274247/comments/14 -- nigelb
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
