[splint-discuss] How to check Uninitialized variable

[Vijayendra Suman]

Hello Ludolf,

Yes, I agree a mix of both that is

   - Valgrind
   - Static analyzer

is fit for my case, but there is a problem particularly in my case which are
as followings

   - 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.
   - 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.
   -  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.

Sincere Regards
Vijayendra Suman





On Wed, May 13, 2009 at 1:45 PM, Ludolf Holzheid <
lholzheid at bihl-wiedemann.de> wrote:

> 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: lholzheid at bihl-wiedemann.de
> D-68199 Mannheim, Germany
> ---------------------------------------------------------------
>
> _______________________________________________
> splint-discuss mailing list
> splint-discuss at mail.cs.virginia.edu
> http://www.cs.virginia.edu/mailman/listinfo/splint-discuss
>



-- 
https://mail.google.com/mail/?ui=2&view=bsp&ver=1qygpcgurkovy
Regards
Vijayendra Suman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.cs.virginia.edu/pipermail/splint-discuss/attachments/20090513/217ec9b9/attachment.html