On Mon, 22 Feb 2010, SF Markus Elfring wrote: > > You can work on the prototype of the file. > > Thanks for your SmPL example. > > > > This will not do as well as Alexander's solution, though, because it might > > be that the prototype will be in a header file that Coccinelle cannot find. > > What are such circumstances when the function signature can not be resolved > as expected?
Coccinelle only looks in the current directory for the header file, or in the one directory that was specified with -I. Some projects have multiple include directories. Coccinelle also does not take into account nested includes. Even with -all_includes, all you get are the include files that are specified in your .c file, not the ones that are included by those file. In Linux, one is supposed to include explicitly the header files that define everything that is directly referenced in the .c file, but this convention might not always be followed, and other projects might not have this convention. On the other hand, including all of the include files, recursively could mean processing really a lot of data that has very littlechance of being useful. Already -all_includes incurs a noticeable slowdown. > > But of course with Coccinelle you can do some transformation on the > > identified function calls. > > Can the data type of the return value be assigned to a SmPL > meta-variable for further processing? You can also match on the prototype of the function with a type metavariable T. After my "ok" rule, you could introduce: @get_type depends on !ok@ identifier r.f; type T; @@ T f (...); Now afterwards when you use r.f you can use get_type.T as well. Actually, if you use get_type.T then you don't need the depends on !ok, because get_type.T is only defined if ok did not match. julia _______________________________________________ Cocci mailing list [email protected] http://lists.diku.dk/mailman/listinfo/cocci (Web access from inside DIKUs LAN only)
