[Cocci] Searching for functions with non-internal linkage

[Cocci] Searching for functions with non-internal linkage

[Markus Elfring]

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

Re: [Cocci] Searching for functions with non-internal linkage

[Julia Lawall]

[-- 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

Re: [Cocci] Searching for functions with non-internal linkage

[Julia Lawall]

[-- 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

Re: [Cocci] Searching for functions with non-internal linkage

[Julia Lawall]

[-- 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

Re: [Cocci] Searching for functions with non-internal linkage

[Julia Lawall]

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

Re: [Cocci] Searching for functions with linkage specifications

[Julia Lawall]

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

Re: [Cocci] Searching for functions with linkage specifications

[Julia Lawall]

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

Re: [Cocci] Searching for functions with linkage specifications

[Julia Lawall]

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

Re: [Cocci] Searching for functions with linkage specifications

[Julia Lawall]

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

Re: [Cocci] Searching for functions with linkage specifications

[Julia Lawall]

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