Related work on C/C++ refactoring

Posted Jan 30, 2009 7:03 UTC (Fri) by padator (guest, #56235)
In reply to: Related work on C/C++ refactoring by tglek
Parent article: Semantic patching with Coccinelle

How long does it take to express the 2 program transformations mentionned in val's article using Pork ? With coccinelle it takes respectively 7 and 9 lines of SmPL, and it can be applied on the whole kernel, including
code in arch/, in code protected by ifdef, etc.

Regarding CPP, how MCPP handles ifdef ? How much of the linux kernel can you analyse ? How many lines MCPP skip to make your parsing job easier ?
How do you handle iterator macros ? In the case of coccinelle we need sometimes to express transformations on macros, on iterators, declarors, and so we must try to not expand macro and represent macro directly in the internal AST.

to post comments

Related work on C/C++ refactoring

Posted Jan 30, 2009 19:24 UTC (Fri) by tglek (guest, #56374) [Link] (2 responses)

Not to make this a contest, but some refactorings require writing a C++ tool, some already have such tools.

So for the rename it'd be a matter of running
./renamer ::alloca ::malloc on the files of interest

For the other change, who knows could be a few lines of C++ or could be a few thousand depending if the complexity of the attempted change(pork's changes can be as complex as the user desires due to having a fully elaborated AST).

Related work on C/C++ refactoring

Posted Jan 30, 2009 19:42 UTC (Fri) by tglek (guest, #56374) [Link]

I should mention that Pork also does not require the user to teach it about various preprocessing constructs used. I know Mozilla code features some phenomenally bad macro expansions(ie defining while method bodies within macros.. or building function bodies out of various macros or otherwise having macros concatenation to call functions) most of which would be extremely unpleasant to explain to any parser.

Instead Pork allows detection of code where macros interfere with a particular refactoring so it can produce an error message and inform the user that some manual help is needed for that particular bad macro. Usually that turns out to be a trivial amount of effort(in the worst possible case it took a couple of days to compensate for it).

Related work on C/C++ refactoring

Posted Jan 30, 2009 19:50 UTC (Fri) by padator (guest, #56235) [Link]

And will your renamer tool also rename code inside ifdefs ? If I run it on the linux kernel, will it also rename functions in arch/alpha/... or
protected by #ifdef DEBUG ?

Coccinelle has also internally a fully elaborated AST and one can write any transformations in OCaml working on this AST but this is precisely what we want to avoid with Coccinelle. We don't want users to express their transformations on the AST but instead to express it easily using our SmPL patch syntax.

Also you didn't really answer my question, how long will it take using Pork to express the second program transformation mentioned in val's article about renaming malloc and also adding the pointer checking code for NULL.