Hi.
If anybody can help with changing the grammar in formatparse.mly please
read below
(paragraph "However, I want to adapt the grammar in formatparse.mly").
On 2/28/2013 8:55 PM, Gabriel Kerneis wrote:
> Hi Alex,
>
> On Thu, Feb 28, 2013 at 12:44:13AM +0200, Alex Susu wrote:
>> More exactly I used to search in the C code the following deconstructors:
>
> Just to make sure I understand you correctly: you are happy with the current
> behaviour, except for the lack of function name support?
I think constructors are very useful, and deconstructors are a good way of
searching
for patterns (normally types) in code.
As far as I understand, interpreted constructors allow more general patterns
than
deconstructors - see end of Section 6.2 for example of big constructor pattern.
On the
other hand, I was able only to specify types for deconstructors. I was thinking
it might
be somewhat useful to match a function by giving to a deconstructor the
prototype of the
function but maybe also some statements within the function.
>> Given the above examples, I would like to have a few extensions to the CIL
>> deconstructors:
>> - specify names of functions - currently adding real function names to
>> deconstructors gives parse error
>
> Agreed, it would be sensible and consistent with matching parameter names.
Indeed, however so far I had a hard time doing this in formatcil.ml. As I
said, I
currently have a hacky implementation, where I am providing separately the
function name
from the type of the function.
However, I want to adapt the grammar in formatparse.mly in order to allow
instead of:
void (*)(int s)
the following:
void MyFunctionName(int s).
Probably the following rule in format.cil is responsible with the above
construct:
LPAREN STAR expression RPAREN offset
(or maybe the rule: STAR attributes decl )
I guess I can get inspired from cparser.mly, from the following function def
rule:
function_def: /* (* ISO 6.9.1 *) */
function_def_start block
...
If anybody has an idea how I can parse constructs with function name, please
help.
>> - maybe specify partial names of formal arguments for functions, or maybe
>> even
>> use some reg-expressions.
>
> Unless you have a compelling use case, I'd be much more reluctant to integrate
> this (my gut feeling is: very high complexity/benefit ratio).
Indeed, especially since we already have a sort of "wildcard" operator on
names of
formals: void (*)(int) matches all function with 1 int argument with any name.
>> As mentioned in cil.pdf, Section 6.2, the one responsible for
>> (de)constructors is
>> formatcil.ml (method doParse, etc). I did a strange hack in this direction,
>> but I'm
>> thinking to add these extensions within the formatcil.ml.
>
> I don't use deconstructors in my own code, but I'd be happy to integrate a
> patch
> adding support for names of functions. Do not hesitate if you stumble on some
> difficulty while you work on it.
>
> Best regards,
Best regards,
Alex
------------------------------------------------------------------------------
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the
endpoint security space. For insight on selecting the right partner to
tackle endpoint security challenges, access the full report.
http://p.sf.net/sfu/symantec-dev2dev
_______________________________________________
CIL-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/cil-users
