> \(foo\|xxx\|yyy\)(...) {
> <...
> - alpha()
> + beta()
> ...>
> }
>
> It works only on the functions foo, xxx, and bar, and does whatever is
> specified in the <... ...>. For further efficiency, you could use <+...
> ...+> That requires there to be at least one of what is inside, and thus
> only functions where something useful can be done will be considered.
You are right of course that this pattern finds also a specific detail in
function implementations.
I try to explain my previous feature request a bit more.
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 make some assumptions here about how your tool works.
1. The analysed source file is converted from a raw input of a character stream
over an abstract syntax tree to an abstract semantic graph, isn't it?
2. Does the internal software infrastructure build a dedicated data structure
like an index about all function declarations and/or definitions?
If the answer to this question would be "No", I imagine that my previous
suggestion would be useful because the additional indexing process will only be
needed if the source code is really filtered in a function body.
Regards,
Markus
_______________________________________________
Cocci mailing list
[email protected]
http://lists.diku.dk/mailman/listinfo/cocci
(Web access from inside DIKUs LAN only)
