Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   C++ (http://www.velocityreviews.com/forums/f39-c.html)
-   -   Re: Tips to analyze a project with thousands of files (http://www.velocityreviews.com/forums/t953690-re-tips-to-analyze-a-project-with-thousands-of-files.html)

ctgqumgf@sharklasers.com 10-21-2012 08:34 AM

Re: Tips to analyze a project with thousands of files
 
Given such a task it might be an option using a static code analyzer. As far as I know fixing a bug also a deadline...

My hope would be that the output of the static code checker can give me some ideas. Well, reading your description I guess there will be hundreds of warnings. I know this game too good.

The art is then to ignore minor warnings (e.g. signed/unsigned assignments/comparisons, ...) and filter out real bad ones (possible division by 0, array out of bounds, access of memory already released, ...).

Given a vague description of the bug (the crash happens when I do this or that) you might be lucky...

I have been working with QAC++ and PC-Lint so far. There might also be open-source tools, like cppcheck which I never had a look at.

[BTW: I cannot tell you how good these tools are at finding dynamic memory problems. There are other tools (like Boundschecker, Purify, ...). But I guess in your case (Qualcomm) they won't help as they normally run instrumented binaries on the host.]

[BTW: GCC with -pedantic option and highest warning level isn't that bad at finding problems either]

Jorgen Grahn 10-21-2012 11:55 AM

Re: Tips to analyze a project with thousands of files
 
On Sun, 2012-10-21, ctgqumgf@sharklasers.com wrote:

[LL has a big heap of unknown code, and they want him/her to fix a bug
which she cannot reproduce herself]

> Given such a task it might be an option using a static code
> analyzer. As far as I know fixing a bug also a deadline...


> My hope would be that the output of the static code checker can give
> me some ideas.


IME, it *is* a good idea to crank up the warning level of the
compiler, and run whatever other static tools you have access to --
but it is rather unlikely that the particular bug you're interested in
shows up there.

Even more unlikely in sloppily written code, which doesn't try to turn
runtime errors into compile-time errors: little use of const, lots of
casts, lots of raw pointers, C code disguised as C++ ...

So yeah, do it, but don't spend too much time on it.

> Given a vague description of the bug (the crash happens when I do
> this or that) you might be lucky...


If it *is* a crash you may be lucky -- any half-decent system gives
you a register and stack dump in that case.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .


All times are GMT. The time now is 07:42 PM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.