>> 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?
Regards,
Markus
_______________________________________________
Cocci mailing list
[email protected]
http://lists.diku.dk/mailman/listinfo/cocci
(Web access from inside DIKUs LAN only)
