On Wed, Mar 12, 2014 at 10:32:15AM -0400, Theodore Ts'o wrote: > On Tue, Mar 11, 2014 at 08:48:41PM -0700, Darrick J. Wong wrote: > > > > I fixed that up in the cppcheck cleanups patch by moving those declarations to > > ext2fs.h. Maybe I should have shoved the patch closer to the head. > > I was going to ask about cppcheck, since I'm not as familiar with it. > We have multiple static code checkers that we are available to > e2fsprogs developers: I've been using cppcheck (http://cppcheck.sourceforge.net/) as a poor man's Coverity to find resource leaks, since I don't have the ability to upload code and run checks myself. Later I would like to use cppcheck's custom rule feature to catch incorrect use of library functions, e.g. modifying an extent without calling ext2fs_extent_fix_parents(), or setting i_blocks directly. Excerpting from https://packages.debian.org/sid/cppcheck, it can catch: * pointers to out-of-scope auto variables; * assignment of auto variables to an effective parameter of a function; * use of deprecated functions (mktemp, gets, scanf); * memory leaks in class or function variables; * C-style pointer cast in C++ code; * redundant if; * misuse of the strtol or sprintf functions; * unsigned division or division by zero; * unused functions and struct members; * passing parameters by value; * misuse of signed char variables; * unusual pointer arithmetic (such as "abc" + 'd'); * dereferenced null pointers; * incomplete statements; It also seems to catch fd leaks. > sparse, via "make C=1" > > gcc -Wall, via "make gcc-wall" and "make gcc-wall-new" > I didn't even realize these existed. I rather like the idea of a make target that builds with as much static analysis as we can muster and spits out a report. > clang, via "CC=clang ./configure ; make" > > converity, via Eric or Ted uploading to scan.coverity.com > > ... and for dynamic testing, we also have: > > valgrind, via "cd build/tests ; make test_script ; ./test_script --valgrind" > or "... ; ./test_scripte --valgrind-leakcheck" > > At this point, the problem is not that we don't have enough testing > tools --- but that we're not using them regularly. Agreed. > I'm not opposed to adding cppcheck, but I'm not familiar with it --- > are there things that it catches that we might not catch via other > means? > > The other thing is that if we can figure out ways to automate running > some of these tests, and perhaps detecting when there are new warnings > that have popped up, that would probably be really useful. > > Also, if anyone feels moved to document ways that e2fsprogs developers > can improve their code submissions, and go hunting for bugs if they so > feel moved, that would probably be a great thing to add to the ext4 > wiki. Yes. I'll start writing a page. https://ext4.wiki.kernel.org/index.php?title=Ext4_Contributing --D -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
