>> @@ >> expression dst, src, n, E; >> @@ >> memcpy(dst, src, sizeof( >> + *( >> E >> - [...] >> + ) >> ) * n >> ) > > That's longer and looks more complicated to me I point another possibility out to express a change specification by the means of the semantic patch language. How would you think about such SmPL code if the indentation will be reduced? > than what we currently have: > @@ > expression dst, src, n, E; > @@ > memcpy(dst, src, n * sizeof( > - E[...] > + *(E) > )) > > Avoiding to duplicate E doesn't seem to be worth it. I show other development preferences occasionally. > I can see that indenting the sizeof parameter and parentheses could > improve readability, though. Thanks that you can follow such coding style aspects. >> @@ >> 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? But this transformation rule can probably be omitted if the usage of SmPL disjunctions will be increased in a subsequent rule, can't it? >> @@ >> type T; >> T* dst_ptr, src_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)) \) >> + , n >> ) > > That x could be anything -- it's not tied to the element size of source > or destination. Such a transformation might change the meaning of the > code, as COPY_ARRAY will use the element size of the destination behind > the scenes. So that doesn't look safe to me. Would you like to use the SmPL code “*( \( src_ptr \| src_arr \) )” instead? >> @@ >> type T; >> T* dst, src, ptr; >> expression n; >> @@ >> ( >> -memmove >> +MOVE_ARRAY >> (dst, src >> - , (n) * \( sizeof(* \( dst \| src \) ) \| sizeof(T) \) >> + , n >> ) >> | >> -ptr = xmalloc((n) * \( sizeof(*ptr) \| sizeof(T) \)) >> +ALLOC_ARRAY(ptr, n) >> ); > > memmove/MOVE_ARRAY and xmalloc/ALLOC_ARRAY are quite different; These functions provide another programming interface. > why would we want to jam transformations for them into the same rule > like this? Possible nicer run time characteristics by the Coccinelle software. > The only overlap seems to be n. These case distinctions can share also the metavariable “T” for the desired source code deletion. > Handling memmove/MOVE_ARRAY and memcpy/COPY_ARRAY together would make > more sense, as they take the same kinds of parameters. Would you like to adjust the SmPL code in such a design direction? > I didn't know that disjunctions can be specified inline using \(, \| > and \), though. Rules can be much more compact that way. I hope that more corresponding software improvements can be achieved. > Mixing languages like that can also be quite confusing. I agree to this development concern. >> Now I observe that the placement of space characters can be a coding style >> concern at four places for adjusted lines by the generated patch. >> Would you like to clarify remaining issues for pretty-printing >> in such use cases? > > Ideally, generated code should adhere to Documentation/CodingGuidelines, > so that it can be accepted without requiring hand-editing. But how does the software situation look like if the original source code would contain coding style issues? It seems to be possible to specify SmPL code in a way so that even questionable code layout would be preserved by an automatic transformation. Regards, Markus
