[Cocci] Checking the influence of an omitted semicolon on a code adjustment

[Cocci] Checking the influence of an omitted semicolon on a code adjustment

[Markus Elfring]

Hello,

The following small SmPL script gets successfully parsed by the Coccinelle software.


@Replacement@
expression call, input, target;
identifier gs;
@@
-\( g_string_assign@gs \| g_string_append@gs \) (target, input);
 call (
-      target
+      gs (target, input)
      );


But if I would like to omit the semicolon in the last line, I stumble on
the error message “incompatible minus and plus code starting on lines 5 and 6”.
Can such a software limitation be adjusted?

Regards,
Markus
_______________________________________________
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] Checking the influence of an omitted semicolon on a code adjustment

[Julia Lawall]

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



On Sat, 28 Nov 2020, Markus Elfring wrote:

> Hello,
>
> The following small SmPL script gets successfully parsed by the Coccinelle software.
>
>
> @Replacement@
> expression call, input, target;
> identifier gs;
> @@
> -\( g_string_assign@gs \| g_string_append@gs \) (target, input);
>  call (
> -      target
> +      gs (target, input)
>       );
>
>
> But if I would like to omit the semicolon in the last line, I stumble on
> the error message “incompatible minus and plus code starting on lines 5 and 6”.
> Can such a software limitation be adjusted?

Why do you want to remove the semicolon?

If you want to find the call somewhere in the next statement, you can say

(
S
&
call(
  ...
  )
)

where S is a statement metavariable.  I'm not sure what will happen if
there are two occurrences of call in the statement.

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] Checking the influence of an omitted semicolon on a code adjustment

[Markus Elfring]

> Why do you want to remove the semicolon?

I have shown a transformation example where a function parameter should be replaced
by a previous function call.
Thus a semicolon should be intentionally be deleted.


> If you want to find the call somewhere in the next statement, you can say
>
> (
> S
> &
> call(
>   ...
>   )
> )
>
> where S is a statement metavariable.

This SmPL specification variant can be also interesting.

I got just interested in the possibility to omit an extra semicolon
in my simple change approach.

Regards,
Markus
_______________________________________________
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] Checking the influence of an omitted semicolon on a code adjustment

[Julia Lawall]

On Sat, 28 Nov 2020, Markus Elfring wrote:

> > Why do you want to remove the semicolon?
>
> I have shown a transformation example where a function parameter should be replaced
> by a previous function call.
> Thus a semicolon should be intentionally be deleted.

That makes no sense.  You can't have an expression directly following a
statement.  Only statements follow other statements.

julia

>
>
> > If you want to find the call somewhere in the next statement, you can say
> >
> > (
> > S
> > &
> > call(
> >   ...
> >   )
> > )
> >
> > where S is a statement metavariable.
>
> This SmPL specification variant can be also interesting.
>
> I got just interested in the possibility to omit an extra semicolon
> in my simple change approach.
>
> Regards,
> Markus
>
_______________________________________________
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] Checking the influence of an omitted semicolon on a code adjustment

[Markus Elfring]

>> I have shown a transformation example where a function parameter should be replaced
>> by a previous function call.
>> Thus a semicolon should be intentionally be deleted.
>
> That makes no sense.

This transformation part is working as expected (under constraints) already.


> You can't have an expression directly following a statement.
> Only statements follow other statements.

This information is reasonable.

Does the Coccinelle software insist on the specification of another semicolon
in the SmPL script for the identification of an adjustable statement?

Regards,
Markus
_______________________________________________
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] Checking the influence of an omitted semicolon on a code adjustment

[Julia Lawall]

On Sat, 28 Nov 2020, Markus Elfring wrote:

> >> I have shown a transformation example where a function parameter should be replaced
> >> by a previous function call.
> >> Thus a semicolon should be intentionally be deleted.
> >
> > That makes no sense.
>
> This transformation part is working as expected (under constraints) already.
>
>
> > You can't have an expression directly following a statement.
> > Only statements follow other statements.
>
> This information is reasonable.
>
> Does the Coccinelle software insist on the specification of another semicolon
> in the SmPL script for the identification of an adjustable statement?

Yes

>
> Regards,
> Markus
>
_______________________________________________
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] Checking the influence of an omitted semicolon on a code adjustment

[Markus Elfring]

>>> You can't have an expression directly following a statement.
>>> Only statements follow other statements.
>>
>> This information is reasonable.
>>
>> Does the Coccinelle software insist on the specification of another semicolon
>> in the SmPL script for the identification of an adjustable statement?
>
> Yes

I imagine that another view can become applicable here.

* It is possible to move a function call with a known property into a parameter
  of a subsequent function/macro call.

* I care more for the implementation detail that a following function/macro
  call exists and less that this source code needs to be an complete statement
  (together with the usual semicolon at the end).


I stumble on further software challenges if I would like to make the simple
transformation approach a bit more variable on the number of surrounding parameters.

Regards,
Markus
_______________________________________________
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] Adjusting some calls according to pass-through functions

[Julia Lawall]

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



On Sun, 29 Nov 2020, Markus Elfring wrote:

> > I stumble on further software challenges if I would like to make the simple
> > transformation approach a bit more variable on the number of surrounding parameters.
>
> It looked promising that another SmPL script variant gets also successfully parsed
> by the current Coccinelle software.
>
>
> @Replacement@
> expression action, input1, input2, input3, target;
> identifier gs;
> @@
> -\( g_string_assign@gs \| g_string_append@gs \| g_string_append_c@gs \) (target, input1);
>  action (
> +        gs (
>              target
> +            , input1)
>              ,
> (            input2, input3
> |            input2
> )       );

I find this way of writing disjunctions really unreadable.  You are saving
some precious whitespace characters at the cost of making any distinction
between what is obligatory and what is optional.

>
> But another test run shows opportunities for further clarification of
> the following software behaviour.
>
>
> elfring@Sonne:~/Projekte/Gnome/Evolution-Data-Server/lokal> spatch --smpl-spacing --max-width 120 src/addressbook/libedata-book/e-book-sqlite.c ~/Projekte/Gnome/use_string_action_return_pointer8.cocci
> …
> previous modification:
> MINUS
>
> According to environment 2:
>    Replacement.input1 -> ' '
>
>    Replacement.gs -> id g_string_append_c
>
>
> current modification:
>
>   <<< gs(
> CONTEXT
>   >>> , input1)
>
>
> According to environment 2:
>    Replacement.input1 -> info->name
>
>    Replacement.gs -> id g_string_append
>
>
> Replacement: already tagged token:
> C code context
> File "src/addressbook/libedata-book/e-book-sqlite.c", line 1909, column 20, charpos = 53094
>   around = 'string',
>   whole content = 	g_string_append_c (string, ' ');
>
>
> The implementation of a function like “format_column_declaration” contains
> the following statements.
> https://gitlab.gnome.org/GNOME/evolution-data-server/-/blob/3de7ea5fdb5d5db4a097a4d888d77bd2778c1c30/src/addressbook/libedata-book/e-book-sqlite.c#L1898
>
> 	g_string_append (string, info->name);
> 	g_string_append_c (string, ' ');
>
> 	g_string_append (string, info->type);
>
> 	if (info->extra) {
> 		g_string_append_c (string, ' ');
> 		g_string_append (string, info->extra);
> 	}

The rule matches for example on the first line and on the second line.
The match on the first line makes a change in the second line.  The match
on the second line removes the second line.  This is a conflict, as
reported.

The problem would be solved in this case by making two separate rules.

julia

>
>
> I imagine that such source code can be transformed into the following variant.
>
> 	g_string_append (g_string_append_c (g_string_append (string, info->name), ' '), info->type);
>
> 	if (info->extra)
> 		g_string_append (g_string_append_c (string, ' '), info->extra);
>
>
> Do you find any extensions interesting for such a code refactoring?
>
> 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] Adjusting some calls according to pass-through functions

[Julia Lawall]

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



On Sun, 29 Nov 2020, Markus Elfring wrote:

> >> @Replacement@
> >> expression action, input1, input2, input3, target;
> >> identifier gs;
> >> @@
> >> -\( g_string_assign@gs \| g_string_append@gs \| g_string_append_c@gs \) (target, input1);
> >>  action (
> >> +        gs (
> >>              target
> >> +            , input1)
> >>              ,
> >> (            input2, input3
> >> |            input2
> >> )       );
> >
> > I find this way of writing disjunctions really unreadable.
>
> I am using different coding styles for SmPL disjunctions because of specific reasons.
>
>
> > You are saving some precious whitespace characters at the cost of making
> > any distinction between what is obligatory and what is optional.
>
> I tend to increase such distinction possibilities.
>
>
> >> The implementation of a function like “format_column_declaration” contains
> >> the following statements.
> >> https://gitlab.gnome.org/GNOME/evolution-data-server/-/blob/3de7ea5fdb5d5db4a097a4d888d77bd2778c1c30/src/addressbook/libedata-book/e-book-sqlite.c#L1898
> >>
> >> 	g_string_append (string, info->name);
> >> 	g_string_append_c (string, ' ');
> >>
> >> 	g_string_append (string, info->type);
> >>
> >> 	if (info->extra) {
> >> 		g_string_append_c (string, ' ');
> >> 		g_string_append (string, info->extra);
> >> 	}
> >
> > The rule matches for example on the first line and on the second line.
>
> Yes. - The transformation approach should work so in principle.
>
>
> > The match on the first line makes a change in the second line.  The match
> > on the second line removes the second line.  This is a conflict,
> > as reported.
>
> I imagine that the error message can be improved somehow.
>
>
> > The problem would be solved in this case by making two separate rules.
>
> I find this suggestion unclear at the moment.

A rule for each of the functions you have in the big disjunction you have
on the first line of your rule.  But it only helps in your case because in
your C code, the first two lines have different function names.

>
> Two changes should be performed in combination for a code replacement.
> How should a separation help then?
>
> Can the shown change pattern be applied recursively?

You can follow the example in demos/iteration.cocci.

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] Adjusting some calls according to pass-through functions

[Julia Lawall]

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



On Sun, 29 Nov 2020, Markus Elfring wrote:

> > A rule for each of the functions you have in the big disjunction
> > you have on the first line of your rule.
>
> I find that the size of such SmPL disjunctions can grow considerably.
>
>
> > But it only helps in your case because in your C code,
> > the first two lines have different function names.
>
> This would be usual for the C programming language.
> Would you ever like to consider additional development challenges for C++
> where distinctions would be more relevant for data types on input parameters?

I don't see any connection between your comment and what I said.  I think
that in both C and C++, people may call the same function on two
subsequent lines.

>
>
> >> Two changes should be performed in combination for a code replacement.
> >> How should a separation help then?
> >>
> >> Can the shown change pattern be applied recursively?
> >
> > You can follow the example in demos/iteration.cocci.
>
> Does a corresponding information like “Modification is not allowed when using iteration.”
> need further clarification for the discussed use case?
> https://github.com/coccinelle/coccinelle/blob/730dbb034559b3e549ec0b2973cd0400a3fa072f/docs/manual/cocci_syntax.tex#L1999

If you use the argument --in-place, there is no restriction.

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] Adjusting some calls according to pass-through functions

[Julia Lawall]

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



On Sun, 29 Nov 2020, Markus Elfring wrote:

> >>> But it only helps in your case because in your C code,
> >>> the first two lines have different function names.
> >>
> >> This would be usual for the C programming language.
> >> Would you ever like to consider additional development challenges for C++
> >> where distinctions would be more relevant for data types on input parameters?
> >
> > I don't see any connection between your comment and what I said.  I think
> > that in both C and C++, people may call the same function on two
> > subsequent lines.
>
> Yes. - This can happen.
>
> The programming language “C++” supports also function overloading.
> Thus the function (or method) name does not need to change for different
> data processing effects.
>
>
> >> Does a corresponding information like “Modification is not allowed when using iteration.”
> >> need further clarification for the discussed use case?
> >> https://github.com/coccinelle/coccinelle/blob/730dbb034559b3e549ec0b2973cd0400a3fa072f/docs/manual/cocci_syntax.tex#L1999
> >
> > If you use the argument --in-place, there is no restriction.
>
> Would you like to add this detail also to the software documentation?

OK

[-- Attachment #2: Type: text/plain, Size: 136 bytes --]

_______________________________________________
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] Adjusting some calls according to pass-through functions

[Julia Lawall]

On Sun, 29 Nov 2020, Markus Elfring wrote:

> > But it only helps in your case because in your C code,
> > the first two lines have different function names.
>
> Would any more software extensions be needed for the discussed use case
> if the same function call would be repeated at subsequent places?

I think it would suffice to iterate over a rule that ensures that the
pattern of interest does not occur before the place where it is matched.
For a more simple exmple:

... when != A(); B();
- A()
  B(
+ A()
  )

julia
_______________________________________________
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] Adjusting some calls according to pass-through functions

[Julia Lawall]

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



On Sun, 29 Nov 2020, Markus Elfring wrote:

> >> Would any more software extensions be needed for the discussed use case
> >> if the same function call would be repeated at subsequent places?
> >
> > I think it would suffice to iterate over a rule that ensures that the
> > pattern of interest does not occur before the place where it is matched.
>
> It seems that I stumble still on understanding difficulties for the application
> of “iteration” according to the SmPL meaning.
>
> Something should provide elements with which an iteration step can work finally.
> I find it challenging to extract such information from mentioned demo scripts.
> https://github.com/coccinelle/coccinelle/blob/730dbb034559b3e549ec0b2973cd0400a3fa072f/docs/manual/cocci_syntax.tex#L1981

When you rule matches, ie you make a change, then you can run Coccinelle
again on the result, by calling something like the add_if_not_present
function shown in the example.

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] Adjusting some calls according to pass-through functions

[Julia Lawall]

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



On Sun, 29 Nov 2020, Markus Elfring wrote:

> >>> I think it would suffice to iterate over a rule that ensures that the
> >>> pattern of interest does not occur before the place where it is matched.
> >>
> >> It seems that I stumble still on understanding difficulties for the application
> >> of “iteration” according to the SmPL meaning.
> >>
> >> Something should provide elements with which an iteration step can work finally.
> >> I find it challenging to extract such information from mentioned demo scripts.
> >> https://github.com/coccinelle/coccinelle/blob/730dbb034559b3e549ec0b2973cd0400a3fa072f/docs/manual/cocci_syntax.tex#L1981
> >
> > When you rule matches, ie you make a change, then you can run Coccinelle
> > again on the result, by calling something like the add_if_not_present
> > function shown in the example.
>
> I find this information only partly reasonable.
>
> I guess that I know the set of identifiers already for which a transformation
> loop could be performed.
> I am unsure about the way to integrate such items into a “demonstrated”
> data processing approach so far.

I think that the only part of the functionality that you need is

it = Iteration()
it.register()

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] Adjusting some calls according to pass-through functions

[Julia Lawall]

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



On Sun, 29 Nov 2020, Markus Elfring wrote:

> >> I guess that I know the set of identifiers already for which a transformation
> >> loop could be performed.
> >> I am unsure about the way to integrate such items into a “demonstrated”
> >> data processing approach so far.
> >
> > I think that the only part of the functionality that you need is
> >
> > it = Iteration()
> > it.register()
>
> Where should I specify the known function names for which a transformation
> should be tried?

In your rule.  In the place of A, in my example.

I would still suggest to have one rule per function, rather than trying to
do everything at once.

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] Adjusting some calls according to pass-through functions

[Julia Lawall]

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



On Sun, 29 Nov 2020, Markus Elfring wrote:

> > In your rule.  In the place of A, in my example.
>
> I find such information too terse.
>
> I hope that the software documentation will be improved further for transformation loops.
>
>
> > I would still suggest to have one rule per function, rather than trying to
> > do everything at once.
>
> I have tried such a SmPL script variant out a moment ago.
>
> elfring@Sonne:~/Projekte/Gnome/Evolution-Data-Server/lokal> spatch --smpl-spacing --max-width 120 src/addressbook/libedata-book/e-book-sqlite.c ~/Projekte/Gnome/use_string_action_return_pointer9.cocci
> init_defs_builtins: /usr/local/bin/../lib/coccinelle/standard.h
> HANDLING: src/addressbook/libedata-book/e-book-sqlite.c
>
> previous modification:
> MINUS
>
> According to environment 2:
>    Replacement2.input1 -> field->dbname
>
>    Replacement2.gs -> id g_string_append
>
>
> current modification:
>
>   <<< gs(
> CONTEXT
>   >>> , input1)
>
>
> According to environment 2:
>    Replacement2.input1 -> ", "
>
>    Replacement2.gs -> id g_string_append
>
>
> Replacement2: already tagged token:
> C code context
> File "src/addressbook/libedata-book/e-book-sqlite.c", line 3629, column 21, charpos = 101199
>   around = 'string',
>   whole content = 				g_string_append (string, field->dbname);

Since you have provided neither your semantic patch nor the source code to
which it is applied, this information is not useful.

> Do you find the implementation of a function like “ebsql_prepare_insert” more interesting then?
> https://gitlab.gnome.org/GNOME/evolution-data-server/-/blob/3de7ea5fdb5d5db4a097a4d888d77bd2778c1c30/src/addressbook/libedata-book/e-book-sqlite.c#L3598

I'm not sure that Coccinelle is well suited for the problem you are trying
to address.  Normally, one works on code fragments that are more disjoint
from each other.

julia

[-- Attachment #2: Type: text/plain, Size: 136 bytes --]

_______________________________________________
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci