Re: coccinelle: adjustments for array.cocci?

From: René Scharfe <l.s.r@web.de>
Date: Nov 16, 2019, 21:38 UTC
Message-ID: <fd15e721-de74-1a4f-be88-7700d583e2f9@web.de>
In-Reply-To: <05ab1110-2115-7886-f890-9983caabc52c@web.de>

Am 16.11.19 um 17:33 schrieb Markus Elfring:

Show 10 quoted lines

>> This reduces duplication in the semantic patch, which is nice.  I think
>> I tried something like that at the time, but found that it failed to
>> produce some of the cases in 921d49be86 ("use COPY_ARRAY for copying
>> arrays", 2019-06-15) for some reason.
>
> I propose to integrate an other solution variant.
>
> * How do you think about to delete questionable transformation rules
>   together with increasing the usage of nested disjunctions in this script
>   for the semantic patch language?

Which transformation rules are questionable and why? Removing broken or ineffective rules would be very welcome.

Specifying disjunctions inline can make rules shorter, but harder to understand due to mixing languages. Perhaps this is a matter of getting used to it, and syntax highlighting might help a bit.

Show 36 quoted lines

> * Can a single transformation rule become sufficient for the discussed
>   change pattern?
>
>
> @@
> type T;
> T* dst_ptr, src_ptr, ptr;
> T[] dst_arr, src_arr;
> expression n, x;
> @@
> (
> -memcpy
> +COPY_ARRAY
>        (
> (       dst_ptr
> |       dst_arr
> )
>        ,
> (       src_ptr
> |       src_arr
> )
> -      , (n) * \( sizeof(T) \| sizeof( \( *(x) \| x[...] \) ) \)
> +      , n
>        )
> |
> -memmove
> +MOVE_ARRAY
>         (dst_ptr,
>          src_ptr
> -               , (n) * \( sizeof(* \( dst_ptr \| src_ptr \) ) \| sizeof(T) \)
> +               , n
>         )
> |
> -ptr = xmalloc((n) * \( sizeof(*ptr) \| sizeof(T) \))
> +ALLOC_ARRAY(ptr, n)
> )

memmove/MOVE_ARRAY take the same kind of parameters as memcpy/COPY_ARRAY, so handling them in the same rule makes sense. The former could take advantage of the transformations for arrays that the latter has.

Mixing in the unrelated xmalloc/ALLOC_ARRAY transformation does not make sense to me, though.

Matching sizeof of anything (with the x) can produce inaccurate transformations, as mentioned in the other reply I just sent.

> Would you like to clarify remaining challenges for pretty-printing
> in such use cases?

Not sure what you mean here. Did my other reply answer it? If it didn't then please state what's unclear to you.

René