On Mon, 23 May 2011, Francis Galiegue wrote:
> On Sun, May 22, 2011 at 21:26, Julia Lawall <[email protected]> wrote:
> [...]
> >>
> >> - the problem is, it also prints the warning if "victim" is static,
> >> which I don't want: how do I tell it about that?
> >
> > One might consider this to be a bug. You can get around it by matching
> > the static variables and then avoiding them. You can see how to do this
> > below.
> >
> >> - the question is, I also want to print the name of the enclosing
> >> function and where it is defined, how do I do that?
> >
> > If you just want the function name, then a position variable has a field
> > current_element that has that information. If you want the line number
> > etc of the start of the function then you have to match the function and
> > put a position variable there. This is done in the semantic patch below.
> > when any means allow anything to appear in the ...s, including another
> > call to amfree. The default is to consider the shortest path between what
> > is before and what is after, which would only give you the first call to
> > amfree. exists means consider each path through the function
> > individually. The default, unless you use * in the leftmost column for
> > matching only, is forall, meaning that all control-flow paths have to
> > satisfy the pattern.
> >
> > julia
> >
> > @bad@
> > position p;
> > identifier i;
> > type T;
> > @@
> >
> > static T i;
> > <...
> > amfree@p(i)
> > ...>
> >
> > @r exists@
> > local idexpression victim;
> > position p!=bad.p;
> > identifier f;
> > position pf;
> > @@
> >
> > f@pf(...) {
> > ... when any
> > amfree@p(victim)
> > ... when != victim
> > }
> >
> > @script:python depends on r@
> > victim << r.victim;
> > p << r.p;
> > pf << r.pf;
> > f << r.f;
> > @@
> >
> > print "%s, line %s: local variable %s is amfree()d but isn't used anywhere
> > else in the file" % (p[0].file, p[0].line, str(victim))
> > print "problem in function %s starting on line %s" % (f,pf[0].line)
> >
>
> This works perfectly!
>
> Coccinelle is really a great tool, getting one's head around its
> language is probably the harder part ;)
>
> What about a step-by-step guide on understanding the language for
> people not (able|wishing) to read EBNF? This would, imho, enable
> Coccinelle to be used even more widely than it is now.
>
> I can already come up with some example C files and "match only"
> semantic patches (associated with some basic python code to print out
> the matching lines, tokens, etc), but I can only do that to my current
> understanding of the language. A complete guide to the language would
> require much more understanding of SmPL than I have, and as I said,
> imho, EBNF is a HUGE obstacle to more mainstream comprehension.
I don't think we really expect anyone to read the grammar, except as a
last resort. We just don't have the resources to put together proper
documentation. And even if one finds a small amount of money to support
work on it, it is hard to find someone who is interested in doing it.
julia
_______________________________________________
Cocci mailing list
[email protected]
http://lists.diku.dk/mailman/listinfo/cocci
(Web access from inside DIKUs LAN only)
