C code analisys tool

[kazak]

Hello,
I am looking for C code analysing tool,

My problem is:
To discover the portion of code that depends on(deals with) a number
of specified structures and variables.
Sample:

void funct(struct header* h)
{
.....

memcpy(buff,h,sizeof(struct header));
func2(buff)
.....
a kind of other code....

}
The idea is to detect all the code that depends on or deals with "h"

Do you know the tools that can solve the problem?

Thanks a lot.
Andrey

 

[jacob navia]

kazak a écrit :

Hello,
I am looking for C code analysing tool,

My problem is:
To discover the portion of code that depends on(deals with) a number
of specified structures and variables.
Sample:

void funct(struct header* h)
{
....

memcpy(buff,h,sizeof(struct header));
func2(buff)
....
a kind of other code....

}
The idea is to detect all the code that depends on or deals with "h"

Do you know the tools that can solve the problem?

Thanks a lot.
Andrey

If you are using the lcc-win32 IDE put the cursor in your identifier and
press CTRL+F8. This will display all usages of that identifier in all
loaded files. If you want to display the usage just within a function
right click in the identifier and choose the "Locals in <function name>"
option from the context menu that appears.

The second option will show a slice of all lines that use the given
identifier ignoring all lines where the identifier does not appear. This
is very handy for seeing the actual usage of a variable

http://www.cs.virginia.edu/~lcc-win32

 

[Ian Collins]

Hello,
I am looking for C code analysing tool,

This sort of thing might be provided by you tool chain, check the docs.

 

[jacob navia]

Ian Collins a écrit :

This sort of thing might be provided by you tool chain, check the docs.

Probably not. This very common option is absent, for instance, in the
latest version of Visual Studio (VC8) even if that software takes 3GB
disk space and as a zillion options.

The gcc IDE DevC++ doesn't do it either. Under linux, most IDEs do not
do any syntax analysis.

Of course

grep MyId *.c

will do it (sort of) but it will not eliminate comments and doesn't
follow scopes.

 

[pibru]

vim+ctags

 

[Ian Collins]

Ian Collins a écrit :


Probably not. This very common option is absent, for instance, in the
latest version of Visual Studio (VC8) even if that software takes 3GB
disk space and as a zillion options.

The gcc IDE DevC++ doesn't do it either. Under linux, most IDEs do not
do any syntax analysis.

That does appear to be a common trend. Bit of a pain for legacy code
support.

Of course

grep MyId *.c

will do it (sort of) but it will not eliminate comments and doesn't
follow scopes.

But it does encourage meaningful names, try greping for 'h'...

 

[jacob navia]

(e-mail address removed) a écrit :

vim+ctags

ctags will give you all usage of a variable within a function?

How do you do that?


Just curious...

jacob

 

[Mark Laczynski]

It sounds to me like you just want to cross reference this h variable.
I would use vim with ctags and/or cscope. To learn how to use any of
these tools w/ vim just check out vim's help system.

Mark

 

[Ben C]

(e-mail address removed) a écrit :

ctags will give you all usage of a variable within a function?

How do you do that?

I don't know if you can do that with ctags, but cscope can give you all
the references to a variable, and, in some versions, all the assignments
to a variable.

But the OP's problem is much harder than this:

OP> My problem is: To discover the portion of code that depends on(deals
OP> with) a number of specified structures and variables. Sample:

OP> void funct(struct header* h)
OP> {
OP> ....
OP>
OP> memcpy(buff,h,sizeof(struct header));
OP> func2(buff)
OP> ....
OP> a kind of other code....
OP>
OP> }

OP> The idea is to detect all the code that depends on or deals with "h"

The type of buff isn't given, but let's assume it's char * for the sake
of argument.

So now anything that deals with buff deals with *h, and we have to follow
a memcpy to see this.

I think a runtime tool would be an easier task than a static tool here.
What's needed is a kind of "radioactive data" where the actual bytes
comprising *h can be made to glow in the dark so we can follow them
through the system.

You could possibly set something up with a combination of gdb's
watchpoints and commands, but if *h is big this might be difficult.

DTrace from Solaris may be able to do the job:

http://www.sun.com/bigadmin/content/dtrace/

 

[kazak]

No greps or cross references can help, cause I don't care about
variable only, I want discover all code that deals with it(it's
execution depends on that variable, but it can be copied in "buff" for
example and tool must look for buff dependent code and futher more...)

Static analisys is the way, have found a lot of tools like CIL, ACL2
and other, but using them does not seem to be a trivial task.

I am going to do it for the piece of code in Linux kernel

 

[kazak]

Any solutions?

 

[Richard Heathfield]

kazak said:

Any solutions?

What kind of solutions? I can do you a nice saline if you like. What are you
talking about? Where's the context?

 

[jacob navia]

kazak a écrit :

Any solutions?

There is no solution.
Nobody has ever done what you want with C in a comprehensive, final way,
because of pointer/address analysis, the difficulties of following
pointers through all possible paths, etc.

For more than VERY simple problems there is no solution.

jacob

 

[Al Balmer]

No greps or cross references can help, cause I don't care about
variable only, I want discover all code that deals with it(it's
execution depends on that variable, but it can be copied in "buff" for
example and tool must look for buff dependent code and futher more...)

Static analisys is the way, have found a lot of tools like CIL, ACL2
and other, but using them does not seem to be a trivial task.

You're right, it's non-trivial. There are two approaches that I have
used, neither very attractive. First, you can use the static analysis
tools plus manual bookkeeping to track all affected uses. In
relatively simple cases this is feasible. Second, you can do something
to 'break" the variable (perhaps just eliminate it) and see what else
breaks. Some things may be broken at compile time, and others only at
run time. This can lead to some hairy debugging, and you'll probably
never be sure you got everything.

 

[CBFalconer]

Any solutions?

To what, or of what?

In general on usenet you should realize that readers may very well
not have convenient access to previous articles in a thread. That
means that your reply articles should include adequate context, so
that they stand by themselves. Google is NOT usenet, it is only a
very poor interface to the real usenet system. To include proper
context when using google, see my sig. below. Please be sure to
read the referenced URLs.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>

 

[Keith Thompson]

Any solutions?

For what?

Read <http://cfaj.freeshell.org/google/>.

 

[kazak]

Got it all.
Thanks to every one.

CBFalconer пиÑал(а):