On Wed, 2 Feb 2011, SF Markus Elfring wrote:
> >> 1. How should update candidates be filtered from the current source file?
> >> - @function_name@(...)
> >> {
> >> ... /* Where is a return value not used as expected? */
> >> }
> >
> > I don't understand the notation.
>
> I would like to suggest another variant for my idea.
>
> My real intention is the specification of a filter pattern that can mostly be
> found/matched within function implementations (without specifying a concrete
> function name before). The current semantic patch language expects that the
> filter pattern contains syntax elements from function blocks (e. g. an
> identifier together with a pair of parentheses and a pair of curly brackets)
> for
> this purpose.
>
> How do you think about this use case if these syntax elements can be omitted?
> Would you like to move this specification for a scope limitation into the SmPL
> meta-variable declaration area (your "@@ block")?
> Can your source code transformation tool perform any optimisations to improve
> the analysis speed because of the knowledge that patterns should only be
> tested
> with the limited scope of function bodies?
I think that all you want is the ability to specify a function like;
\(foo\|xxx\|yyy\)(...) {
<...
- alpha()
+ beta()
...>
}
This could (moderately) easily be added. Currently, you would have to
have separate rules fo foo, xxx, and yyy, which is a bit awkward.
julia
_______________________________________________
Cocci mailing list
[email protected]
http://lists.diku.dk/mailman/listinfo/cocci
(Web access from inside DIKUs LAN only)
