On 08/25/2011 05:13 PM, Julia Lawall wrote:
> 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.
It just works(TM). Brilliant as it is a very trivial solution.
>>> 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.
I know (*), that's why I have shot for the lexer patch as that is the
time when macro transformation should happen. Using an example like this
command line switch "-C_define interface=struct" would have probably
been a better idea but it doesn't shows that I really want to do the
macro substitution and have that in the resulting diff.
(*) Disclaimer: I don't know anything about compilers nor do I have a CS
background, I just follow and use coccinelle for two years now.
Sometimes my regexp loving alter ego wishes that coccinelle would know
less C and just do the "trivial" search and replace. And I blissfully
ignored the fact that the parser doesn't do transformation and the SmPL
rules don't affect the parser.
bye
michael
_______________________________________________
Cocci mailing list
[email protected]
http://lists.diku.dk/mailman/listinfo/cocci
(Web access from inside DIKUs LAN only)
