Hello Ludolf,<br><br>Yes, I agree a mix of both that is <br><ul><li>Valgrind</li><li>Static analyzer</li></ul>is fit for my case, but there is a problem particularly in my case which are as followings <br><ul><li>I am still working on the making the H/W board based on Arm Processor up which will take some more time, this why i want to make sure the code is clean and ready to run on the target so that i do not waste time to debug problems which may be avoided before hand.<br>
</li><li>The code base is very big and so not all code paths will be executed even if my H/W is ready in next 1-2 weeks, so valgrind will only help in the control path of executed code.</li><li> And to be sorry the code base has a mix of C, C++ codes and taking a look at all the code will take some time.<br>
</li></ul>Sincere Regards<br>Vijayendra Suman<br><br><br><br><br><br><div class="gmail_quote">On Wed, May 13, 2009 at 1:45 PM, Ludolf Holzheid <span dir="ltr"><<a href="mailto:lholzheid@bihl-wiedemann.de">lholzheid@bihl-wiedemann.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">On Tue, 2009-05-12 14:22:21 -0400, Jeff Johnson wrote:<br>
><br>
> There's a fundamental issue wrto static annotations (like splint) vs.<br>
> run-time instrumentation (like valgrind).<br>
><br>
> Identifying (and statically annotating) every possible path in<br>
> a program is -- in general -- infeasible.<br>
><br>
> Consider a code path that depends on how an application is configured.<br>
> Sure one can add assertions to indicate the domain of application<br>
> of splint annotations.<br>
><br>
> But are splint annotations the correct tool for eliminating<br>
> uninitialized<br>
> variables?<br>
><br>
> Its rather easy to find uninitialized variables using valgrind instead.<br>
<br>
</div>Well, the two tools, while identifying similar programming mistakes,<br>
do totally different things:<br>
<br>
o Static code analysis identifies suspicious source code lines,<br>
no matter if executed or not, while<br>
<br>
o run-time code analysis detects program misbehavior if and only if<br>
the path is actually executed during the test.<br>
<br>
It depends on the kind of the program and the execution environment<br>
the program runs in, which of the two matches your needs and which is<br>
available at all.<br>
<br>
For instance, Vijayendra wants to check code that seems to depend on<br>
GCC extensions. This locks splint out. I use splint to check my own<br>
sources (so I can arrange them with splint in mind).<br>
<br>
My code is to run on deeply embedded, highly specialized hardware, for<br>
which valgrind is not available. Moreover, as my software is<br>
safety-related, it is full of safety-bags such as non-empty default<br>
clauses in switch statements that already handle all possible values<br>
of the switch expression. It is not feasible to actually execute all<br>
of these paths (the hard way is error injection).<br>
<br>
Vijayendra's target system seems to be a hosted execution environment,<br>
without the stringent constraints of my (free-standing) execution<br>
environment, so I expect valgrind to be available. I wouldn't want to<br>
write a test program to run an exhaustive test for the glibc under<br>
valgrind, though.<br>
<div class="im"><br>
> All I really mean to point out is that splint can't find every flaw,<br>
> nor can valgrind. The combination of tools is far better than either.<br>
<br>
</div>Of course, if both tools are available and usable, the combination of<br>
the tools is best. But this is not always the case.<br>
<div class="im"><br>
Ludolf<br>
<br>
--<br>
<br>
---------------------------------------------------------------<br>
Ludolf Holzheid Tel: +49 621 339960<br>
Bihl+Wiedemann GmbH Fax: +49 621 3392239<br>
Floßwörthstraße 41 e-mail: <a href="mailto:lholzheid@bihl-wiedemann.de">lholzheid@bihl-wiedemann.de</a><br>
D-68199 Mannheim, Germany<br>
---------------------------------------------------------------<br>
<br>
_______________________________________________<br>
</div><div><div></div><div class="h5">splint-discuss mailing list<br>
<a href="mailto:splint-discuss@mail.cs.virginia.edu">splint-discuss@mail.cs.virginia.edu</a><br>
<a href="http://www.cs.virginia.edu/mailman/listinfo/splint-discuss" target="_blank">http://www.cs.virginia.edu/mailman/listinfo/splint-discuss</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><a href="https://mail.google.com/mail/?ui=2&view=bsp&ver=1qygpcgurkovy">https://mail.google.com/mail/?ui=2&view=bsp&ver=1qygpcgurkovy</a><br>Regards <br>
Vijayendra Suman<br>