Hi, Gabriel,
     I am almost done with the changes of the grammar.
     My biggest concern so far is that after changing in the grammar in 
formatparse.mly 1 
rule, I had to erase another rule, which was used instead of my rule at parse 
time.
     Should I send you the new grammar with some explanation on your personal 
email?

     Does anybody know well the grammar specification from formatparse.mly?

     I also wonder why formatparse.mly (and probably also cparser.mly) has some 
rules like 
this:
         decl:
         |  STAR attributes decl
                     { ((fun ts args ->
                          let al = (fst $2) args in
                          (fst $3) (TPtr(ts, al)) args),

                        (fun (fn, ft) ->
                          match (snd $3) (fn, ft) with
                            Some (TPtr(bt, al), m2) -> begin
                              match (snd $2) al with
                                Some m1 -> Some (bt, m1 @ m2)
                              | _ -> None
                            end
                          | _ -> None))
                     }
       So, the rule returns a tuple of 2 functions, one curried, one uncurried. 
I have a 
bit of hard time understanding why do we have such tuple with 2 functions - 
some 
explanation is warmly welcome.

        Maybe of interest: I wrote some ideas on how to debug grammar specs for 
ocamlyacc 
at https://sites.google.com/site/alexsusu/home/cil - search for section 
Tracing...

   Best regards,
     Alex

On 5/12/2013 1:28 AM, Gabriel Kerneis wrote:
> On Sat, May 11, 2013 at 08:55:02AM +0300, Alex Susu wrote:
>>     I am starting now to experience with the grammar in
>> formatparse.mly - will let you know of the outcome.
>
> I'm still not sure if it's a good idea or not, but please do send a patch and
> we'll discuss it.  My main concern is that the name would be parsed but then
> necessarily discarded (since it is not stored in the type TFun), which might 
> be
> misleading.
>
>>    Would there be an interest to add an dStmt deconstructor, as well?
>
> Probably not, dLval and dExp should be enough in most cases I guess.
>
> Best regards,

------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d
_______________________________________________
CIL-users mailing list
CIL-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cil-users

Reply via email to