> 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? >>> 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? >>>> @@ >>>> 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@xxxxxx/ >> 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? >> 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
