On Thu, 25 Aug 2011, Michael Stefaniuc wrote: > Julia Lawall wrote: > > On Thu, 25 Aug 2011, Michael Stefaniuc wrote: > > > >> Arie Middelkoop wrote: > >>>>> In SmPL pseudo > >>>>> (and invalid) code I'm looking for something that does: > >>>>> @@ > >>>>> macro interface; > >>>>> @@ > >>>>> - interface > >>>>> + struct > >>>>> > >>>>> Just using perl (interface is a very common word in the comments) or > >>>>> removing/modifying the define (it is used in macro expansion (API) as > >>>>> well in generated code from IDL) is very tedious and I wonder if there > >>>>> is a cleaner way to achieve it; preferably in coccinelle. > >>>> I'm not seeing anything very obvious. The problem is that the SmPL code > >>>> doesn't take into account the macro definition file. So it won't know > >>>> what to do with interface. > >>> What if you could define an additional set of keywords and for each > >>> keyword a mapping to a sequence of tokens? > >>> In that case, you can perform such substitutions before the actual parse > >>> process starts. This would work for your particular problem: but it's > >>> rather early in the entire process to be really useful. > >>> (not to mention that I'm not sure if it is possible to 'dynamically' > >>> extend the lexer) > >> It doesn't need to be dynamic. What I have done is to add in > >> parsing_c/lexer_c.mll in the keyword_table > >> "interface", (fun ii -> Tstruct ii); > >> There is already a section there for Windows extensions. > >> No clue yet if this is enough as I didn't have time to test it; I'll do > >> that tonight at home. > > > > The problem is not the C lexer but the SmPL one. Perhaps it would be > > enough for you to make the analogous change there > > (parsing_cocci/lexer_cocci.mll). > Aah, sorry. For the task at hand having having "struct foo" in SmPL > match "interface foo" in C is good enough. I can then manually change > "interface" to "struct".
OK. I don't know if it will match, though. The matching process may look at the actual string. > > The "macro" that you propose is sort of like the typedef that exists > > already in SmPL. The problem though is that for typedef we know that the > > labelled thing should represent a type. But for macro it could be > > anything. > Yes, something like that. Perhaps I was not clear. But Coccinelle needs to know what kind of thing a thing is. For example the matching of expressions only compares SmPL expressions to C expressions. The AST distinguishes between all of these kinds of terms. But a macro can represent anything, so it would destroy the AST representation. Perhaps it could be done with inheritance, but it would require a total rewrite to the entire implementation. julia > Not sure if this would be useful for other > people. But the Win32 API has other "nice stuff" that would be > problematic to match with coccinelle: > #define CONST const > I'm fixing those at the moment en-pasant with a search and replace of > the diff generated by coccinelle. > > thanks > bye > michael > _______________________________________________ Cocci mailing list [email protected] http://lists.diku.dk/mailman/listinfo/cocci (Web access from inside DIKUs LAN only)
