[cocci] Searching function implementations with more than a single return?

[cocci] Searching function implementations with more than a single return?

[Markus Elfring]

Hello,

May I expect that a function like usb_ss_max_streams() can be found with the help
of the following source code search pattern?
https://elixir.bootlin.com/linux/v6.16-rc3/source/include/uapi/linux/usb/ch9.h#L721-L737

Another SmPL script example:
@display@
statement list sl;
identifier i;
type t;
@@
(return ...;
|
?t i;
*sl
)


Markus_Elfring@Sonne:…/Projekte/Linux/next-analyses> time /usr/bin/spatch --no-loops …/Projekte/Coccinelle/janitor/show_functions_with_more_than_single_return.cocci include/uapi/linux/usb/ch9.h
…
real    0m0,245s
user    0m0,214s
sys     0m0,028s


Regards,
Markus

Re: [cocci] Searching function implementations with variable declarations and statements?

[Markus Elfring]

> May I expect that a function like usb_ss_max_streams() can be found with the help
> of the following source code search pattern?

Another SmPL script example:
@display2@
statement list sl;
identifier i;
type t;
@@
 <+...
*t i;
 ...+>
 sl


Should any diff output be produced accordingly?

Markus_Elfring@Sonne:…/Projekte/Linux/next-analyses> time /usr/bin/spatch --no-loops …/show_variable_declarations_before_statements.cocci include/uapi/linux/usb/ch9.h
…
real    0m0,138s
user    0m0,101s
sys     0m0,035s


Regards,
Markus

Re: [cocci] Searching function implementations with variable declarations and statements?

[Julia Lawall]

[-- Attachment #1: Type: text/plain, Size: 749 bytes --]



On Tue, 1 Jul 2025, Markus Elfring wrote:

> > May I expect that a function like usb_ss_max_streams() can be found with the help
> > of the following source code search pattern?
>
> Another SmPL script example:
> @display2@
> statement list sl;
> identifier i;
> type t;
> @@
>  <+...
> *t i;
>  ...+>
>  sl
>
>
> Should any diff output be produced accordingly?

Probably not.  Statement list metavariables only match the list of
statements that occur at top level within {}.

julia

>
> Markus_Elfring@Sonne:…/Projekte/Linux/next-analyses> time /usr/bin/spatch --no-loops …/show_variable_declarations_before_statements.cocci include/uapi/linux/usb/ch9.h
> …
> real    0m0,138s
> user    0m0,101s
> sys     0m0,035s
>
>
> Regards,
> Markus
>

Re: [cocci] Searching function implementations with variable declarations and statements?

[Markus Elfring]

>> Should any diff output be produced accordingly?
> Probably not.  Statement list metavariables only match the list of
> statements that occur at top level within {}.

Do you occasionally prefer a source code search approach like the following?

Another SmPL script example:
@display2@
statement s;
identifier i;
type t;
@@
 <+...
*t i;
 ...+>
 s


Markus_Elfring@Sonne:…/Projekte/Linux/next-analyses> time /usr/bin/spatch --no-loops …/Projekte/Coccinelle/janitor/show_variable_declarations_before_statements2.cocci include/…
@@ -666,7 +666,6 @@ static inline int usb_endpoint_maxp(cons
…
@@ -721,7 +720,6 @@ struct usb_ss_ep_comp_descriptor {
…
real    0m0,250s
user    0m0,202s
sys     0m0,048s


Regards,
Markus

Re: [cocci] Searching function implementations with variable declarations and statements?

[Julia Lawall]

[-- Attachment #1: Type: text/plain, Size: 862 bytes --]



On Tue, 1 Jul 2025, Markus Elfring wrote:

> >> Should any diff output be produced accordingly?
> > Probably not.  Statement list metavariables only match the list of
> > statements that occur at top level within {}.
>
> Do you occasionally prefer a source code search approach like the following?
>
> Another SmPL script example:
> @display2@
> statement s;
> identifier i;
> type t;
> @@
>  <+...
> *t i;
>  ...+>
>  s

This seems more promising.

julia

>
>
> Markus_Elfring@Sonne:…/Projekte/Linux/next-analyses> time /usr/bin/spatch --no-loops …/Projekte/Coccinelle/janitor/show_variable_declarations_before_statements2.cocci include/…
> @@ -666,7 +666,6 @@ static inline int usb_endpoint_maxp(cons
> …
> @@ -721,7 +720,6 @@ struct usb_ss_ep_comp_descriptor {
> …
> real    0m0,250s
> user    0m0,202s
> sys     0m0,048s
>
>
> Regards,
> Markus
>

Re: [cocci] Searching function implementations with variable declarations and statements?

[Markus Elfring]

> May I expect that a function like usb_ss_max_streams() can be found with the help
> of the following source code search pattern?

Another SmPL script example:
@display3@
statement list sl;
identifier i;
type t;
@@
 <+...
 t i;
 ...+>
*sl


Should any diff output be produced accordingly?

Markus_Elfring@Sonne:…/Projekte/Linux/next-analyses> time /usr/bin/spatch --no-loops …/Projekte/Coccinelle/janitor/show_statements_after_variable_declaration.cocci include/uapi/linux/usb/ch9.h
…
real    0m0,118s
user    0m0,094s
sys     0m0,025s


Regards,
Markus

Re: [cocci] Searching function implementations with variable declarations and statements?

[Markus Elfring]

> Should any diff output be produced accordingly?

Would you occasionally really find a source code search approach like the following
more appropriate?

Another SmPL script example:
@display3@
statement s;
identifier i;
type t;
@@
 t i;
 <+...
*s
 ...+>


Markus_Elfring@Sonne:…/Projekte/Linux/next-analyses> time /usr/bin/spatch --no-loops …/Projekte/Coccinelle/janitor/show_statements_after_variable_declaration2.cocci include/
…
@@ -668,7 +668,6 @@ usb_endpoint_maxp_mult(const struct usb_
…
@@ -723,17 +722,10 @@ usb_ss_max_streams(const struct usb_ss_e
…
real    0m0,243s
user    0m0,199s
sys     0m0,042s


Is there a need to reconsider the handling of curly brackets (for compound statements)?

Regards,
Markus

Re: [cocci] Searching function implementations with variable declarations and statements?

[Julia Lawall]

[-- Attachment #1: Type: text/plain, Size: 862 bytes --]



On Tue, 1 Jul 2025, Markus Elfring wrote:

> > Should any diff output be produced accordingly?
>
> Would you occasionally really find a source code search approach like the following
> more appropriate?
>
> Another SmPL script example:
> @display3@
> statement s;
> identifier i;
> type t;
> @@
>  t i;
>  <+...
> *s
>  ...+>

You don't need the +

julia

>
>
> Markus_Elfring@Sonne:…/Projekte/Linux/next-analyses> time /usr/bin/spatch --no-loops …/Projekte/Coccinelle/janitor/show_statements_after_variable_declaration2.cocci include/
> …
> @@ -668,7 +668,6 @@ usb_endpoint_maxp_mult(const struct usb_
> …
> @@ -723,17 +722,10 @@ usb_ss_max_streams(const struct usb_ss_e
> …
> real    0m0,243s
> user    0m0,199s
> sys     0m0,042s
>
>
> Is there a need to reconsider the handling of curly brackets (for compound statements)?
>
> Regards,
> Markus
>

Re: [cocci] Searching function implementations with variable declarations and statements?

[Markus Elfring]

>> Another SmPL script example:
>> @display3@
>> statement s;
>> identifier i;
>> type t;
>> @@
>>  t i;
>>  <+...
>> *s
>>  ...+>
> You don't need the +

Would we occasionally like to show a “list” of statements (detailed control flow)?

Regards,
Markus

Re: [cocci] Searching function implementations with variable declarations and statements?

[Julia Lawall]

[-- Attachment #1: Type: text/plain, Size: 550 bytes --]



On Tue, 1 Jul 2025, Markus Elfring wrote:

> >> Another SmPL script example:
> >> @display3@
> >> statement s;
> >> identifier i;
> >> type t;
> >> @@
> >>  t i;
> >>  <+...
> >> *s
> >>  ...+>
> > You don't need the +
>
> Would we occasionally like to show a “list” of statements (detailed control flow)?

What you like doesn't really matter in this case.  The only thing that is
supported is when the list of statements is precisely the body of a {}.
There is no unit in the cfg that a metavariable can be mapped to in the
other cases.

julia

Re: [cocci] Searching function implementations with more than a single return?

[Markus Elfring]

> Another SmPL script example:

for further development considerations?

@display@
identifier i;
statement s;
statement list sl;
type t;
@@
(return ...;
|t i;
(
 <+...
*s
 ...+>
|
*sl
)
)


Markus_Elfring@Sonne:…/Projekte/Linux/next-analyses> time /usr/bin/spatch --no-loops …/Projekte/Coccinelle/janitor/show_functions_with_more_than_single_return2.cocci include/uapi/linux/usb/ch9.h
…
@@ -668,7 +668,6 @@ usb_endpoint_maxp_mult(const struct usb_
…
@@ -723,17 +722,10 @@ usb_ss_max_streams(const struct usb_ss_e
…
real    0m0,250s
user    0m0,217s
sys     0m0,030s


Regards,
Markus

Re: [cocci] Searching function implementations with more than a single return?

[Julia Lawall]

[-- Attachment #1: Type: text/plain, Size: 825 bytes --]



On Tue, 1 Jul 2025, Markus Elfring wrote:

> > Another SmPL script example:
>
> for further development considerations?
>
> @display@
> identifier i;
> statement s;
> statement list sl;
> type t;
> @@
> (return ...;
> |t i;
> (
>  <+...
> *s
>  ...+>
> |
> *sl
> )
> )

This one makes no sense, because return and t i; can't match the same
thing.  So the disjunction has no impact.

julia

>
>
> Markus_Elfring@Sonne:…/Projekte/Linux/next-analyses> time /usr/bin/spatch --no-loops …/Projekte/Coccinelle/janitor/show_functions_with_more_than_single_return2.cocci include/uapi/linux/usb/ch9.h
> …
> @@ -668,7 +668,6 @@ usb_endpoint_maxp_mult(const struct usb_
> …
> @@ -723,17 +722,10 @@ usb_ss_max_streams(const struct usb_ss_e
> …
> real    0m0,250s
> user    0m0,217s
> sys     0m0,030s
>
>
> Regards,
> Markus
>

Re: [cocci] Searching function implementations with more than a single return?

[Markus Elfring]

>>> Another SmPL script example:
>> for further development considerations?
>>
>> @display@
>> identifier i;
>> statement s;
>> statement list sl;
>> type t;
>> @@
>> (return ...;
>> |t i;
>> (
>>  <+...
>> *s
>>  ...+>
>> |
>> *sl
>> )
>> )
> 
> This one makes no sense, because return and t i; can't match the same
> thing.  So the disjunction has no impact.
Would you like to suggest the exclusion of a single return statement
by a more appropriate source code search approach?

Regards,
Markus

Re: [cocci] Searching function implementations with more than a single return?

[Julia Lawall]

On Tue, 1 Jul 2025, Markus Elfring wrote:

> >>> Another SmPL script example:
> >> for further development considerations?
> >>
> >> @display@
> >> identifier i;
> >> statement s;
> >> statement list sl;
> >> type t;
> >> @@
> >> (return ...;
> >> |t i;
> >> (
> >>  <+...
> >> *s
> >>  ...+>
> >> |
> >> *sl
> >> )
> >> )
> >
> > This one makes no sense, because return and t i; can't match the same
> > thing.  So the disjunction has no impact.
> Would you like to suggest the exclusion of a single return statement
> by a more appropriate source code search approach?

Requiring the presence of a declaration already excludes the case of a
single return.  If you want to exclude a single return after a
declaration, then the return should be put in the disjunctions with the
*s.  The *sl will again never match anything, because it's not coming
immediately after a {}.  It comes immediately after a declaration.

julia

Re: [cocci] Searching function implementations with more than a single return?

[Markus Elfring]

>> Would you like to suggest the exclusion of a single return statement
>> by a more appropriate source code search approach?
> Requiring the presence of a declaration already excludes the case of a
> single return.

Variable declarations (and definition) can also be specified after
a return statement, can't they?


>                 If you want to exclude a single return after a
> declaration, then the return should be put in the disjunctions with the
> *s.  The *sl will again never match anything, because it's not coming
> immediately after a {}.  It comes immediately after a declaration.

Is the handling of curly brackets (for compound statements) still unclear
so far?

Regards,
Markus

Re: [cocci] Searching function implementations with more than a single return?

[Julia Lawall]

On Tue, 1 Jul 2025, Markus Elfring wrote:

> >> Would you like to suggest the exclusion of a single return statement
> >> by a more appropriate source code search approach?
> > Requiring the presence of a declaration already excludes the case of a
> > single return.
>
> Variable declarations (and definition) can also be specified after
> a return statement, can't they?

In terms of execution, nothing happens after a return statesment.

And anyway, after the return is not the issue here.  You have a pattern
that at each node in the CFG searches for either a return or a variable
declaration.  In the case of a return it does nothing.  Since no node can
match both the disjunction doesn't have any useful effect.

>
>
> >                 If you want to exclude a single return after a
> > declaration, then the return should be put in the disjunctions with the
> > *s.  The *sl will again never match anything, because it's not coming
> > immediately after a {}.  It comes immediately after a declaration.
>
> Is the handling of curly brackets (for compound statements) still unclear
> so far?

I see nothing unclear.  You can write { sl }.  You can't write S1 sl S2.
There exists no representation of a list of statements that sl can bind
to.

julia

Re: [cocci] Searching function implementations with more than a single return?

[Markus Elfring]

> I see nothing unclear.  You can write { sl }.  You can't write S1 sl S2.
> There exists no representation of a list of statements that sl can bind to.
It seems that such bits of information point opportunities out for further
contributors to improve also the software documentation accordingly.

Regards,
Markus

Re: [cocci] Search challenges for “statement lists”?

[Markus Elfring]

>                         You can write { sl }.

Such a source code search pattern can occasionally be helpful.
https://gitlab.inria.fr/coccinelle/coccinelle/-/blob/b00c5adb1a485321c88450bdaa9e0d9ff93123dc/docs/manual/cocci_syntax.tex#L348-350


>                                                You can't write S1 sl S2.

Which software constraints would hinder the application of such a metavariable combination
so far?


> There exists no representation of a list of statements that sl can bind to.
Is there a need to clarify further possible software extensions?

Regards,
Markus

Re: [cocci] Using statement list combinations?

[Markus Elfring]

> I see nothing unclear.  You can write { sl }.  You can't write S1 sl S2.
Would you find an SmPL code variant (like the following) more reasonable?

@display@
statement header, footer;
statement list sl;
@@
*header { sl } footer


Regards,
Markus

Re: [cocci] Using statement list combinations?

[Julia Lawall]

On Thu, 3 Jul 2025, Markus Elfring wrote:

> > I see nothing unclear.  You can write { sl }.  You can't write S1 sl S2.
> Would you find an SmPL code variant (like the following) more reasonable?
>
> @display@
> statement header, footer;
> statement list sl;
> @@
> *header { sl } footer

I don't know what you expect it to match.

julia

>
>
> Regards,
> Markus
>

Re: [cocci] Using statement list combinations?

[Markus Elfring]

>> Would you find an SmPL code variant (like the following) more reasonable?
>>
>> @display@
>> statement header, footer;
>> statement list sl;
>> @@
>> *header { sl } footer
> 
> I don't know what you expect it to match.

Such a source code search approach is very generic.
I am curious how often this code pattern could be found finally.

Regards,
Markus

Re: [cocci] Using statement list combinations?

[Julia Lawall]

On Thu, 3 Jul 2025, Markus Elfring wrote:

> >> Would you find an SmPL code variant (like the following) more reasonable?
> >>
> >> @display@
> >> statement header, footer;
> >> statement list sl;
> >> @@
> >> *header { sl } footer
> >
> > I don't know what you expect it to match.
>
> Such a source code search approach is very generic.
> I am curious how often this code pattern could be found finally.

Probably never.  People don't often make a {} between two other
statements.

julia

Re: [cocci] Using statement list combinations?

[Markus Elfring]

>> I am curious how often this code pattern could be found finally.
> Probably never.  People don't often make a {} between two other statements.

I imagine that source code analyses would occasionally care more for
the implementation detail if curly brackets should enclose extra compound statements
(or not).
Is there a need to mark data processing scopes better anyhow?

Regards,
Markus