Hi Alex, On Tue, Mar 12, 2013 at 12:04:26PM +0200, Alex Susu wrote: > 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.
The reason what you are trying to do doesn't work is because the name of formal parameters is part of the type of the function, whereas it's name is not. I'm not sure whether this is part of the C standard or an artifact of how CIL handles types, but it explains the limitation you have hit. Formatparse is not the culprit here: the identifier is parsed correctly (in the "decl" rule indeed), but ignored by dType because it does not belong to the type at all (see the definition of TFun in cil.mli). On the other hand, you are not restricted to types for deconstructors: you can match expressions (dExp), lvalues (dLval) and instructions (dInstr). A dStmt seems to be missing, however. You would need to change the "stmt" rule of formatparse.mly, making a pair of constructor/deconstructor functions and using fst/snd for cStmt/dStmt in formatcil.ml, just like it is done for "instr". No idea how hard it would be to implement. Best, -- Gabriel ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar _______________________________________________ CIL-users mailing list CIL-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cil-users
