On Tue, 2009-05-12 14:22:21 -0400, Jeff Johnson wrote: > > There's a fundamental issue wrto static annotations (like splint) vs. > run-time instrumentation (like valgrind). > > Identifying (and statically annotating) every possible path in > a program is -- in general -- infeasible. > > Consider a code path that depends on how an application is configured. > Sure one can add assertions to indicate the domain of application > of splint annotations. > > But are splint annotations the correct tool for eliminating > uninitialized > variables? > > Its rather easy to find uninitialized variables using valgrind instead.
Well, the two tools, while identifying similar programming mistakes, do totally different things: o Static code analysis identifies suspicious source code lines, no matter if executed or not, while o run-time code analysis detects program misbehavior if and only if the path is actually executed during the test. It depends on the kind of the program and the execution environment the program runs in, which of the two matches your needs and which is available at all. For instance, Vijayendra wants to check code that seems to depend on GCC extensions. This locks splint out. I use splint to check my own sources (so I can arrange them with splint in mind). My code is to run on deeply embedded, highly specialized hardware, for which valgrind is not available. Moreover, as my software is safety-related, it is full of safety-bags such as non-empty default clauses in switch statements that already handle all possible values of the switch expression. It is not feasible to actually execute all of these paths (the hard way is error injection). Vijayendra's target system seems to be a hosted execution environment, without the stringent constraints of my (free-standing) execution environment, so I expect valgrind to be available. I wouldn't want to write a test program to run an exhaustive test for the glibc under valgrind, though. > All I really mean to point out is that splint can't find every flaw, > nor can valgrind. The combination of tools is far better than either. Of course, if both tools are available and usable, the combination of the tools is best. But this is not always the case. Ludolf -- --------------------------------------------------------------- Ludolf Holzheid Tel: +49 621 339960 Bihl+Wiedemann GmbH Fax: +49 621 3392239 Floßwörthstraße 41 e-mail: lholzh...@bihl-wiedemann.de D-68199 Mannheim, Germany --------------------------------------------------------------- _______________________________________________ splint-discuss mailing list splint-discuss@mail.cs.virginia.edu http://www.cs.virginia.edu/mailman/listinfo/splint-discuss
