On Mon, 31 Jan 2011, SF Markus Elfring wrote:
> > If you want to do something with functions that have a type other than
> > void, you can do:
> > @r@
> > identifier f;
> > @@
>
> Does the semantic patch language provide the capability to distinguish
> identifiers between variable, macro and function names (for SmPL type safety)
> explicitly?
No. There was supposed to be a metavariable type function for that
purpose, but it was never completely implemented.
> > @depends on !isvoid@
> > identifier r.f;
> > @@
> >
> > {here f is a non-void function}
>
> I imagine an alternative way to specify the detection of return values from
> function calls which are not appropriately reused and then to add
> corresponding
> source code adjustments.
>
> The difficulty for this patch application is that an adjustment should
> only be applied after a source code analysis came to the conclusion that
> a return value was really not used within a function implementation. The
> function implementation needs to be completely processed before this
> fact becomes available for further design decisions.
There is no problem with this. Coccinelle does the complete matching
process, and then does transformation afterwards for things that have
matched.
> (How do you filter
> source files and match against anything in them efficiently if this
> "thing" does not exist already because it is just missing?)
You match the cases that satisfy the property you want, and then report on
the other cases, as in the example I sent to Anders.
> I propose the addition of callbacks or triggers to the semantic patch
> language.
> Examples:
> - Whenever the instruction "return" is detected, a SmPL rule could be executed
> (eventually including an OCaml or Python script).
> - Whenever the parsing detects that the end of a function body was reaches, an
> other SmPL rule could be called.
I think this is too complicated and not needed. You can just match the
return, and then write a smpl rule or script rule afterwards, possibly
using depends on if there is no other way to make the connection between
the rules.
> I suggest to map parts of the functionality that is known as pointcuts in
> other
> aspect-oriented programming languages to new constructs in the SmPL grammar.
> http://en.wikipedia.org/wiki/Pointcut
>
> Would you like to add support for the handling of such advices with your
> patch data format?
Not really. If someone wants to do aspect-oriented programming there are
perhaps better tools for that.
julia
_______________________________________________
Cocci mailing list
[email protected]
http://lists.diku.dk/mailman/listinfo/cocci
(Web access from inside DIKUs LAN only)
