* [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, other threads:[~2020-09-22 19:33 UTC | newest]
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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).