Julia,

Thanks for the -use_cache suggestion.  I will try it
out on the next script.

I tried it out on a small sample:

as-was         19m 12s
1st -use_cache 19m 18s
2nd -use_cache 16m 21s
3rd -use_cache 16m 15s

2nd/3rd was just to double check.

A 16% improvement is worth having :-)

Bug: Specifying -use_cache results in a spurious TODO being sent
to stderr.

I did wonder about what information Coccinelle might be able to
provide for 'free', ie information it always collects when
processing code but does not provide a means to access.
For instance, the number of definitions and statements in a
function definition,

It's not clear what this means, because statements can be nested.

Whatever can be made available can be of use.

or the code matched by ... .

It doesn't know this.  The implementation of ... keeps track of what is
reachable from what, but not how it is reachable.  How it is reachable
would be difficult to calculate in the presence of loops.  It would be
conceptually possible to keep track of the set of control-flow graph nodes
matched, but that is not currently expressible.

I was hoping that it might be possible to internally figure out
something like:  if we start here and end here the code involved must
be foo___bar

The obvious script has the problem that it does not supply
parameter number information:

You just need a parameter list metavariable:

parameter list[n] ps;

Afterwards, you can use either n or ps.  ps can be empty/n can be 0.

I don't see a way this would enable me to match the 1st/2nd parameter
of a function containing just two parameters or the 1st/2nd/3rd
parameter of a function containing just three parameters.

At the time looking for differences based on how many parameters
a function was defined with sounded like a good idea.

When you inherit n into python it is a string (although when you inherit n
into ocaml, it is an integer).

julia

@ fn_p_any @
type ret_T, pany_T;
identifier fn, p_any;
@@

ret_T fn(..., pany_T p_any, ...)
{
... when != p_any
}

@script:python @
param_any<<  fn_p_any.p_any;
func<<  fn_p_any.fn;
@@
print "unused", func, param_any

so I wrote lots of patterns like:

@ fn_no_p1 @
type ret_T, p1_T;
identifier fn, p1;
@@

ret_T fn(p1_T p1)
{
... when != p1
}

@script:python @
param_1<<  fn_no_p1.p1;
func<<  fn_no_p1.fn;
@@
print "1_1", func, param_1

to match particular instances.


julia


Trying out a new idea with something that takes 300+ hours to run is a bit
impractical.

Does anybody have any thoughts on:

     o converting the source to some intermediate form that will
speed up Coccinelle processing,

     o using Coccinelle in the cloud, eg Amazon,

     o speeding up Coccinelle.

--
Derek M. Jones                         tel: +44 (0) 1252 520 667
Knowledge Software Ltd                 mailto:[email protected]
Source code analysis                   http://www.knosof.co.uk
_______________________________________________
Cocci mailing list
[email protected]
http://lists.diku.dk/mailman/listinfo/cocci
(Web access from inside DIKUs LAN only)




--
Derek M. Jones                         tel: +44 (0) 1252 520 667
Knowledge Software Ltd                 mailto:[email protected]
Source code analysis                   http://www.knosof.co.uk
_______________________________________________
Cocci mailing list
[email protected]
http://lists.diku.dk/mailman/listinfo/cocci
(Web access from inside DIKUs LAN only)



--
Derek M. Jones                         tel: +44 (0) 1252 520 667
Knowledge Software Ltd                 mailto:[email protected]
Source code analysis                   http://www.knosof.co.uk
_______________________________________________
Cocci mailing list
[email protected]
http://lists.diku.dk/mailman/listinfo/cocci
(Web access from inside DIKUs LAN only)

Reply via email to