Hello, I have tried another tiny script variant out for the semantic patch language (according to the software combination “Coccinelle 1.0.8-00177-g28737419”). @find@ identifier i; type t; @@ t i(...) { ... } @find_static@ identifier find.i; type find.t; @@ static t i(...) { ... } @display depends on !find_static@ identifier find.i; type find.t; @@ *t i(...) { ... } This source code analysis approach is generally working in the way it is designed. Can the same data processing results be achieved also with a single SmPL rule? Regards, Markus _______________________________________________ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci
[-- Attachment #1: Type: text/plain, Size: 859 bytes --] On Mon, 21 Sep 2020, Markus Elfring wrote: > Hello, > > I have tried another tiny script variant out for the semantic patch language > (according to the software combination “Coccinelle 1.0.8-00177-g28737419”). > > @find@ > identifier i; > type t; > @@ > t i(...) > { ... } > > @find_static@ > identifier find.i; > type find.t; > @@ > static t i(...) > { ... } > > @display depends on !find_static@ > identifier find.i; > type find.t; > @@ > *t i(...) > { ... } > > > This source code analysis approach is generally working in the way > it is designed. > Can the same data processing results be achieved also with a single SmPL rule? There is an isomorphism related to static. Maybe optional_qualifier. That is, in the third rule, if you remove the depends on and add disable optional_qualifier, then it would not match a static function. julia [-- Attachment #2: Type: text/plain, Size: 136 bytes --] _______________________________________________ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci
[-- Attachment #1: Type: text/plain, Size: 955 bytes --] On Mon, 21 Sep 2020, Markus Elfring wrote: > >> Can the same data processing results be achieved also with a single SmPL rule? > > > > There is an isomorphism related to static. Maybe optional_qualifier. > > I interpret the available information in the way that the isomorphism “optional_storage” > affects the handling of visibility for identifiers like function names. > https://github.com/coccinelle/coccinelle/blob/730dbb034559b3e549ec0b2973cd0400a3fa072f/docs/manual/cocci_syntax.tex#L125 > > > > That is, in the third rule, if you remove the depends on and add disable > > optional_qualifier, then it would not match a static function. > > Would such a setting be better than the dependency check according to > the SmPL rule “find_static”? Optional_storage is indeed probably the right one. julia > > How are the chances to determine functions which are not marked as “static” > by one SmPL rule directly? > > Regards, > Markus > [-- Attachment #2: Type: text/plain, Size: 136 bytes --] _______________________________________________ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci
[-- Attachment #1: Type: text/plain, Size: 839 bytes --] On Mon, 21 Sep 2020, Markus Elfring wrote: > >>> That is, in the third rule, if you remove the depends on and add disable > >>> optional_qualifier, then it would not match a static function. > >> > >> Would such a setting be better than the dependency check according to > >> the SmPL rule “find_static”? > > > > Optional_storage is indeed probably the right one. > > The following SmPL script variant seems to work as expected then. > > @find disable optional_storage@ > identifier i; > type t; > @@ > ( > *t i(...) > { ... } > | > *extern t i(...) > { ... } > ) > > > Can another SmPL script variant become similarly useful? > > @find2 disable optional_storage@ > identifier i; > type t; > @@ > ( > *t > | > *extern t > ) > *i(...) > { ... } I doubt that this parses. I don't think extern t is considered to be a type. julia [-- Attachment #2: Type: text/plain, Size: 136 bytes --] _______________________________________________ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci
On Tue, 22 Sep 2020, Markus Elfring wrote: > >> Can another SmPL script variant become similarly useful? > >> > >> @find2 disable optional_storage@ > >> identifier i; > >> type t; > >> @@ > >> ( > >> *t > >> | > >> *extern t > >> ) > >> *i(...) > >> { ... } > > > > I doubt that this parses. > > I hope to achieve further improvements also for this application area. > > > > I don't think extern t is considered to be a type. > > Which entity should take care of this key word (in SmPL disjunctions)? I don't know if a disjunction is allowed at this level. But if it is allowed, then it would be with extern and maybe inline, etc. julia _______________________________________________ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci
On Tue, 22 Sep 2020, Markus Elfring wrote: > > I doubt that this parses. > > Can another report for a parsing error be reconsidered also for the following > SmPL script variant? > > @display disable optional_storage@ > identifier i; > type t; > @@ > ( > *extern > | > *static > ) > *t i(...) > { ... } When you use a yacc generated parser, you don't have any control over where it decides to report an error. julia _______________________________________________ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci
On Tue, 22 Sep 2020, Markus Elfring wrote: > >> Can another report for a parsing error be reconsidered also for the following > >> SmPL script variant? > >> > >> @display disable optional_storage@ > >> identifier i; > >> type t; > >> @@ > >> ( > >> *extern > >> | > >> *static > >> ) > >> *t i(...) > >> { ... } > > > > When you use a yacc generated parser, you don't have any control over > > where it decides to report an error. > > How do you think about to choose an alternative parsing approach? This question is completely absurd. Have you ever actually written a parser? > > Would you find the shown case distinction useful? Disjunctions could be added for extern and static. Feel free to propose a patch. julia _______________________________________________ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci
On Tue, 22 Sep 2020, Markus Elfring wrote: > >>> When you use a yacc generated parser, you don't have any control over > >>> where it decides to report an error. > >> > >> How do you think about to choose an alternative parsing approach? > > > > This question is completely absurd. > > It is known that YACC-like parsing has got limitations. > Thus I am curious under which circumstances possible alternatives > can become more attractive. > > > > Have you ever actually written a parser? > > I came also along special parsing needs for specific data structures. > > > >> Would you find the shown case distinction useful? > > > > Disjunctions could be added for extern and static. > > Thanks for this kind of feedback. > > > > Feel free to propose a patch. > > Can any clarification help to make such a contribution easier? I think you can follow the model of other kinds of disjunctions. julia _______________________________________________ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci
On Tue, 22 Sep 2020, Markus Elfring wrote: > > I think you can follow the model of other kinds of disjunctions. > > Which (OCaml) modules do take care of the corresponding data processing? Probably all files in parsing_cocci and cocci_vs_c.ml julia _______________________________________________ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci
On Tue, 22 Sep 2020, Markus Elfring wrote: > >>> I think you can follow the model of other kinds of disjunctions. > >> > >> Which (OCaml) modules do take care of the corresponding data processing? > > > > Probably all files in parsing_cocci and cocci_vs_c.ml > > Can the dependencies become clearer for the evaluation of SmPL disjunctions > by such software components? Just grep for Disj. You will find all of the relevant files. julia _______________________________________________ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci