Re: coccinelle: adjustments for array.cocci?

From: Markus Elfring <markus.elfring@web.de>
Date: Nov 17, 2019, 18:19 UTC
Message-ID: <eff19da9-3f9f-0cf0-1e88-64d2acdbabcd@web.de>
In-Reply-To: <37c84512-ba83-51ce-4253-ea0f7bd41de0@web.de>

> 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?

Show 8 quoted lines

>>> 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?

Show 35 quoted lines

>>>> @@
>>>> 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”?

>> 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/

>> 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?

Show 5 quoted lines

>   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?

>> 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.

>> 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