On Wed, 14 Oct 2009, Joe Perches wrote: > On Wed, 2009-10-14 at 19:29 -0700, Luis R. Rodriguez wrote: > > FWIW, coccinelle spatch should work better but I have found issues > > with spatch on headers, it just won't touch them, for instance. What are you trying to do? By default Coccinelle tries to avoir headers to reduce parsing time. But if you think header files are relevant, there are some options you can use. 1) If you want to increase the number of header files that are included when processing a C file, use -all_includes. This makes more type information available, for example. Header files will be processed, indeed, as many times as they are included, which is not completely ideal. 2) If the goal is to process the header files just like the .c files, then you can use the option -include-headers. Furthermore, if typing information is irrelevant to your problem, then -no_include -include_headers works well. > But > > in this case wouldn't it be safer to use it first for all C files > > and then leave a script to finish he job later? > > Knock yourself out. I don't know about better, but > coccinelle would certainly work different. > > You'll still need to integrated the split format strings, > which coccinelle doesn't do, reformat/align the > pr_<foo>/dev_<foo> arguments, indent the modified source, > (I used a diff/emacs script), etc. > > You might also extract the embedded function names > from the constant format strings, and use %s...__func__. Indeed, Coccinelle doesn't help currently with work that involves looking inside format strings. We have recently (unreleased) added matching according to regular expressions for identifier names. It would be an even better idea to add this for strings. I think this could be done fairly easily. For the moment the regular expression support is fairly minimal, ie only matching, not extracting fragments of the matched string. Still that might be enough to help find the places where changes shold be made, and then the actual changes could be done by some other script. julia _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel