> Is @function_name@ the name of the function whose return value is ignored 
> elsewhere,

No. - It specifies a scope for the desired source code analysis.

You registered a feature request about the handling of variable function names
yesterday, didn't you?   ;-)


> or is it the name of a function in whose body you want to find 
> ignored return values.

Yes. - That is my intention.


> The following finds a call whose result is never used until the end of the 
> function or until reaching a reassignment.  (? marks something that is 
> optional).
> 
> @@
> identifier x;
> expression fn,E;
> @@
> 
> x = fn(...);
> + ???
> ... when != x
> ?x = E
> 
> You can put whatever you want in the ??? line.

I know that. But the source code adjustment can not always be directly performed
after a found function call. Several conditions must be fulfilled to choose an
appropriate patch.

It might be that a part of my difficulties is that I do not know so far if
pattern grouping is supported as an alternative way by SmPL in comparison to my
previous suggestion of patch callbacks/triggers.


> But what you would want to put there depends on the return value of fn.

Maybe. - A query for the function return type would be only useful if I would
try to construct a variable assignment or object initialisation as a potential
repair.
Otherwise: I would need more introspection capabilities to take special function
properties into account.
Example: Was the affected function implementation called from within a signal
handler call hierarchy? Does my "fix" need to be "async-signal-safe"?


> If you want to see how to collect information about certain kinds of return 
> values, 
> then that is presented in the "advanced SmPL" slides on this page: 
> http://coccinelle.lip6.fr/papers.php and in demos/iteration.cocci.

I have read your examples that result in a few final Python print instructions
which displays informations from SmPL position variables.


> Otherwise, maybe the programmer should just think about it himself.

I would appreciate if a general adjustment rule will become possible.

Would it be easier to express an use case like "A Reusable Aspect for Memory
Allocation Checking" as a SmPL demonstration for a start in the requested 
direction?
http://research.msrg.utoronto.ca/ACC/Tutorial#A_Reusable_Aspect_for_Memory_All

Regards,
Markus
_______________________________________________
Cocci mailing list
[email protected]
http://lists.diku.dk/mailman/listinfo/cocci
(Web access from inside DIKUs LAN only)

Reply via email to