Coccinelle Archive on lore.kernel.org
 help / color / Atom feed
* [Cocci] Searching for functions with non-internal linkage
@ 2020-09-21 12:32 Markus Elfring
  2020-09-21 13:22 ` Julia Lawall
  0 siblings, 1 reply; 10+ messages in thread
From: Markus Elfring @ 2020-09-21 12:32 UTC (permalink / raw)
  To: Coccinelle

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [Cocci] Searching for functions with non-internal linkage
  2020-09-21 12:32 [Cocci] Searching for functions with non-internal linkage Markus Elfring
@ 2020-09-21 13:22 ` Julia Lawall
       [not found]   ` <38815e95-833b-e2fd-4630-8ae7cfe54aa7@web.de>
  0 siblings, 1 reply; 10+ messages in thread
From: Julia Lawall @ 2020-09-21 13:22 UTC (permalink / raw)
  To: Markus Elfring; +Cc: Coccinelle


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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [Cocci] Searching for functions with non-internal linkage
       [not found]   ` <38815e95-833b-e2fd-4630-8ae7cfe54aa7@web.de>
@ 2020-09-21 13:48     ` Julia Lawall
       [not found]       ` <12c105f8-80e3-b47d-3bc5-141d6011fe89@web.de>
  0 siblings, 1 reply; 10+ messages in thread
From: Julia Lawall @ 2020-09-21 13:48 UTC (permalink / raw)
  To: Markus Elfring; +Cc: Coccinelle


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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [Cocci] Searching for functions with non-internal linkage
       [not found]       ` <12c105f8-80e3-b47d-3bc5-141d6011fe89@web.de>
@ 2020-09-21 14:27         ` Julia Lawall
       [not found]           ` <6746e72b-ad50-7b03-f059-8e22e21d32c9@web.de>
       [not found]           ` <1367af30-cbff-dd2d-f17d-5b9464fad359@web.de>
  0 siblings, 2 replies; 10+ messages in thread
From: Julia Lawall @ 2020-09-21 14:27 UTC (permalink / raw)
  To: Markus Elfring; +Cc: Coccinelle


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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [Cocci] Searching for functions with non-internal linkage
       [not found]           ` <6746e72b-ad50-7b03-f059-8e22e21d32c9@web.de>
@ 2020-09-22  9:29             ` Julia Lawall
  0 siblings, 0 replies; 10+ messages in thread
From: Julia Lawall @ 2020-09-22  9:29 UTC (permalink / raw)
  To: Markus Elfring; +Cc: Coccinelle



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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [Cocci] Searching for functions with linkage specifications
       [not found]           ` <1367af30-cbff-dd2d-f17d-5b9464fad359@web.de>
@ 2020-09-22 10:28             ` Julia Lawall
       [not found]               ` <cf0e8aa0-67f0-966c-4fa4-6942331069a6@web.de>
  0 siblings, 1 reply; 10+ messages in thread
From: Julia Lawall @ 2020-09-22 10:28 UTC (permalink / raw)
  To: Markus Elfring; +Cc: Coccinelle



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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [Cocci] Searching for functions with linkage specifications
       [not found]               ` <cf0e8aa0-67f0-966c-4fa4-6942331069a6@web.de>
@ 2020-09-22 12:37                 ` Julia Lawall
       [not found]                   ` <eaacd91c-4752-2031-266f-243557dd0f72@web.de>
  0 siblings, 1 reply; 10+ messages in thread
From: Julia Lawall @ 2020-09-22 12:37 UTC (permalink / raw)
  To: Markus Elfring; +Cc: Coccinelle



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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [Cocci] Searching for functions with linkage specifications
       [not found]                   ` <eaacd91c-4752-2031-266f-243557dd0f72@web.de>
@ 2020-09-22 12:54                     ` Julia Lawall
       [not found]                       ` <245d6cf2-438b-ed0c-ac60-d5448b408cb2@web.de>
  0 siblings, 1 reply; 10+ messages in thread
From: Julia Lawall @ 2020-09-22 12:54 UTC (permalink / raw)
  To: Markus Elfring; +Cc: Coccinelle



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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [Cocci] Searching for functions with linkage specifications
       [not found]                       ` <245d6cf2-438b-ed0c-ac60-d5448b408cb2@web.de>
@ 2020-09-22 13:14                         ` Julia Lawall
       [not found]                           ` <3bae0270-a34a-9133-daaf-8be0de0bbcbb@web.de>
  0 siblings, 1 reply; 10+ messages in thread
From: Julia Lawall @ 2020-09-22 13:14 UTC (permalink / raw)
  To: Markus Elfring; +Cc: Coccinelle



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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [Cocci] Searching for functions with linkage specifications
       [not found]                           ` <3bae0270-a34a-9133-daaf-8be0de0bbcbb@web.de>
@ 2020-09-22 19:33                             ` Julia Lawall
  0 siblings, 0 replies; 10+ messages in thread
From: Julia Lawall @ 2020-09-22 19:33 UTC (permalink / raw)
  To: Markus Elfring; +Cc: Coccinelle



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

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, back to index

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-09-21 12:32 [Cocci] Searching for functions with non-internal linkage Markus Elfring
2020-09-21 13:22 ` Julia Lawall
     [not found]   ` <38815e95-833b-e2fd-4630-8ae7cfe54aa7@web.de>
2020-09-21 13:48     ` Julia Lawall
     [not found]       ` <12c105f8-80e3-b47d-3bc5-141d6011fe89@web.de>
2020-09-21 14:27         ` Julia Lawall
     [not found]           ` <6746e72b-ad50-7b03-f059-8e22e21d32c9@web.de>
2020-09-22  9:29             ` Julia Lawall
     [not found]           ` <1367af30-cbff-dd2d-f17d-5b9464fad359@web.de>
2020-09-22 10:28             ` [Cocci] Searching for functions with linkage specifications Julia Lawall
     [not found]               ` <cf0e8aa0-67f0-966c-4fa4-6942331069a6@web.de>
2020-09-22 12:37                 ` Julia Lawall
     [not found]                   ` <eaacd91c-4752-2031-266f-243557dd0f72@web.de>
2020-09-22 12:54                     ` Julia Lawall
     [not found]                       ` <245d6cf2-438b-ed0c-ac60-d5448b408cb2@web.de>
2020-09-22 13:14                         ` Julia Lawall
     [not found]                           ` <3bae0270-a34a-9133-daaf-8be0de0bbcbb@web.de>
2020-09-22 19:33                             ` Julia Lawall

Coccinelle Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/cocci/0 cocci/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 cocci cocci/ https://lore.kernel.org/cocci \
		cocci@systeme.lip6.fr
	public-inbox-index cocci

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/fr.lip6.systeme.cocci


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git