Re: coccinelle: adjustments for array.cocci?

Whitespace is not what makes the above example more complicated than the
equivalent rule below;

A different code layout might help in a better understanding for such
change specifications.

separating the pieces of simple expressions does.

Will there occasionally be a need to change only the required source code parts?

quoted

quoted

than what we currently have:
  @@
  expression dst, src, n, E;
  @@
    memcpy(dst, src, n * sizeof(
  - E[...]
  + *(E)
    ))

Are any circumstances to consider where only the essential implementation details
should be touched by an automatic software transformation?

quoted

quoted

quoted

@@
type T;
T *ptr;
T[] arr;
expression E, n;
@@
 memcpy(
(       ptr, E, sizeof(
-                      *(ptr)
+                      T
                      ) * n
|       arr, E, sizeof(
-                      *(arr)
+                      T
                      ) * n
|       E, ptr, sizeof(
-                      *(ptr)
+                      T
                      ) * n
|       E, arr, sizeof(
-                      *(arr)
+                      T
                      ) * n
)
       )

This still fails to regenerate two of the changes from 921d49be86
(use COPY_ARRAY for copying arrays, 2019-06-15), at least with for me
(and Coccinelle 1.0.4).

Would you become keen to find the reasons out for unexpected data processing
results (also by the software combination “Coccinelle 1.0.8-00004-g842075f7”)
at this place?

It looks like a bug in Coccinelle to me

We might stumble also on just another (temporary) software limitation.

and I'd like to see it fixed

Would you like to support corresponding development anyhow?

if that's confirmed, of course.

I am curious if further feedback will evolve for affected software areas.

And I'd like to see Debian pick up a newer version, preferably containing that fix.

I assume that you can wait a long time for progress in the software
distribution direction.

But at least until then our semantic patches need to work around it.

Would another concrete fix for the currently discussed SmPL script
be better than a “workaround”?

quoted

But this transformation rule can probably be omitted if the usage
of SmPL disjunctions will be increased in a subsequent rule, can't it?

Perhaps, but I don't see how.  Do you?

Obviously, yes (in principle according to my proposal from yesterday).
https://public-inbox.org/git/05ab1110-2115-7886-f890-9983caabc52c@web.de/

quoted

Would you like to use the SmPL code “*( \( src_ptr \| src_arr \) )” instead?

That leaves out dst_ptr and dst_arr.

How many items should finally be filtered in the discussed SmPL disjunction?

And what would it mean to match e.g. this ?

	memcpy(dst_ptr, src_ptr, n * sizeof(*src_arr))

The Coccinelle software takes care for commutativity by isomorphisms.
https://github.com/coccinelle/coccinelle/blob/19ee1697bf152d37a78a20cefe148775bf4b0e0d/standard.iso#L241

At least the element size would be the same, but I'd rather shy away from
transforming weird cases like this automatically.

Do you mean to specify additional restrictions by SmPL code?

  void *memmove(void *dest, const void *src, size_t n);
  void *memcpy(void *dest, const void *src, size_t n);

  COPY_ARRAY(dst, src, n)
  MOVE_ARRAY(dst, src, n)

Can the replacement of these functions by macro calls be combined further
by improved SmPL code?

quoted

Possible nicer run time characteristics by the Coccinelle software.

How much faster is it exactly?

The answer will depend on efforts which you would like to invest
in corresponding (representative) measurements.

Speedups are good, but I think readability of rules is more important
than coccicheck duration.

I hope that a more pleasing balance can be found for the involved
usability factors.

quoted

But how does the software situation look like if the original source code
would contain coding style issues?

The same: Generated code should not add coding style issues.

Such an expectation is generally nice. - But target conflicts can occur there.

We can still use results that need to be polished, but that's a manual step
which reduces the benefits of automation.

I am curious how the software development practice will evolve further.

Regards,
Markus