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
>_______________________________________________
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci
