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