>> + memcpy( >> +( ptr, E, n * >> +- sizeof(*(ptr)) >> ++ sizeof(T) >> +| arr, E, n * >> +- sizeof(*(arr)) >> ++ sizeof(T) >> +| E, ptr, n * >> +- sizeof(*(ptr)) >> ++ sizeof(T) >> +| E, arr, n * >> +- sizeof(*(arr)) >> ++ sizeof(T) >> ) >> + ) > > This seems quite unreadable, in contrast to the original code. The code formatting can vary for improved applications of SmPL disjunctions. See also related update suggestions: * https://public-inbox.org/git/05ab1110-2115-7886-f890-9983caabc52c@xxxxxx/ * https://public-inbox.org/git/75b9417b-14a7-c9c6-25eb-f6e05f340376@xxxxxx/ >> 5. I stored another generated patch based on the adjusted SmPL script. > > No idea what it means to store a patch. I put the output from the program “spatch” into a text file like “array-reduced1.diff” in a selected directory. >> 6. I performed a corresponding file comparison. >> >> --- array-released.diff 2019-11-14 21:29:11.020576916 +0100 >> +++ array-reduced1.diff 2019-11-14 21:45:58.931956527 +0100 >> @@ -6,24 +6,10 @@ >> r->entry_count = t->entry_count; >> r->delta_depth = t->delta_depth; >> - memcpy(r->entries,t->entries,t->entry_count*sizeof(t->entries[0])); >> -+ COPY_ARRAY(r->entries, t->entries, t->entry_count); >> ++ memcpy(r->entries,t->entries,t->entry_count*sizeof(*(t->entries))); >> release_tree_content(t); >> return r; >> } > > I have no idea what is being compared here. I suggest to take another look at the described steps then. > The COPY_ARRAY thing looks nice, but doesn't seem to have anything to do > with your semantic patch. I find your interpretation of the presented software situation questionable. * I got the impression in the meantime that my suggestion for a refactoring of a specific SmPL disjunction influenced transformation results for a subsequent SmPL rule in unexpected ways. * Other software adjustments and solution variants can trigger further development considerations, can't they? Regards, Markus
