Re: [Cocci] git-coccinelle: adjustments for array.cocci?

[Markus Elfring]

>> + memcpy(
>> +(   ptr, E, n *
>> +-   sizeof(*(ptr))
>> ++   sizeof(T)
>> +|   arr, E, n *
>> +-   sizeof(*(arr))
>> ++   sizeof(T)
>> +|   E, ptr, n *
>> +-   sizeof(*(ptr))
>> ++   sizeof(T)
>> +|   E, arr, n *
>> +-   sizeof(*(arr))
>> ++   sizeof(T)
>>  )
>> +   )
>
> This seems quite unreadable, in contrast to the original code.

The code formatting can vary for improved applications of SmPL disjunctions.

See also related update suggestions:
* https://public-inbox.org/git/05ab1110-2115-7886-f890-9983caabc...@web.de/
* https://public-inbox.org/git/75b9417b-14a7-c9c6-25eb-f6e05f340...@web.de/


>> 5. I stored another generated patch based on the adjusted SmPL script.
>
> No idea what it means to store a patch.

I put the output from the program “spatch” into a text file like 
“array-reduced1.diff”
in a selected directory.


>> 6. I performed a corresponding file comparison.
>>
>> --- array-released.diff  2019-11-14 21:29:11.020576916 +0100
>> +++ array-reduced1.diff  2019-11-14 21:45:58.931956527 +0100
>> @@ -6,24 +6,10 @@
>>  r->entry_count = t->entry_count;
>>  r->delta_depth = t->delta_depth;
>>  -   memcpy(r->entries,t->entries,t->entry_count*sizeof(t->entries[0]));
>> -+   COPY_ARRAY(r->entries, t->entries, t->entry_count);
>> ++   memcpy(r->entries,t->entries,t->entry_count*sizeof(*(t->entries)));
>>  release_tree_content(t);
>>  return r;
>>   }
>
> I have no idea what is being compared here.

I suggest to take another look at the described steps then.


> The COPY_ARRAY thing looks nice, but doesn't seem to have anything to do
> with your semantic patch.

I find your interpretation of the presented software situation questionable.

* I got the impression in the meantime that my suggestion for a refactoring
  of a specific SmPL disjunction influenced transformation results for
  a subsequent SmPL rule in unexpected ways.

* Other software adjustments and solution variants can trigger further
  development considerations, can't they?

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

Re: [Cocci] git-coccinelle: adjustments for array.cocci?

[Markus Elfring]

> It can determine the type of t->entries if it has access to the definition
> of the type of t.

I would like to point another implementation detail out.

Another known function was also an update candidate.
https://github.com/git/git/blob/9a1180fc304ad9831641e5788e9c8d3dfc10ccdd/pretty.c#L90

elfring@Sonne:~/Projekte/git/lokal> spatch contrib/coccinelle/array.cocci 
pretty.c
…
@@ -106,8 +106,8 @@ static void setup_commit_formats(void)
commit_formats_len = ARRAY_SIZE(builtin_formats);
builtin_formats_len = commit_formats_len;
ALLOC_GROW(commit_formats, commit_formats_len, commit_formats_alloc);
-   memcpy(commit_formats, builtin_formats,
-  sizeof(*builtin_formats)*ARRAY_SIZE(builtin_formats));
+   COPY_ARRAY(commit_formats, builtin_formats,
+  ARRAY_SIZE(builtin_formats));

git_config(git_pretty_formats_config, NULL);
 }


This patch generation can work based on the following SmPL code combination.

“…
expression n, x;
…
-  , (n) * \( sizeof(T) \| sizeof(*(x)) \)
…”

The asterisk should refer to a pointer expression within a sizeof operator.
I got informed that the semantic patch language would support such a 
restriction.

Thus I have tried out to specify the corresponding metavariables in this way.

“…
expression n;
expression* x;
…”

But the shown diff hunk is not regenerated by this SmPL script variant.
How should an array like “builtin_formats” (which is even defined in the same 
function)
be treated by the Coccinelle software in such use cases?

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