>> This case distinction can share a few metavariables with the other >> transformation approach, can't it? > > Can it can, but should it? In my opinion it should not; I presented a software design in an other direction. Some data processing approaches can benefit from sharing common information. > separate concerns should get their own rules. Strict separation triggers corresponding consequences. > That's easier to manage for developers. This view can be reasonable. > I suspect it's also easier for Coccinelle to evaluate, but didn't check. I find such an assumption questionable. > I use MAKEFLAGS += -j6, which runs six spatch instances in > parallel for the coccicheck make target of Git instead. The program “spatch” supports parallelisation also directly by the parameter “--jobs”. Did you try it out occasionally? > OK, so --profile allows to analyze in which of its parts Coccinelle > spends the extra time. Some information about time distribution will be displayed. >> I suggest to use a search for (pointer) expressions instead. >> This approach can trigger other consequences then. > > Why don't we need to check the type? I got the impression that we stumble on a general challenge for generic source code searches. How many efforts would we like to invest in solving type safety issues? >> Would you eventually work with SmPL script variants in parallel according >> to different confidence settings? > > Me? No. Such a view can be fine. But I am also still trying to improve various implementation details despite of known software limitations. > If I can't trust automatic transformations then I don't want them. I need to live with compromises together also with current development tools. > I can already generate bugs fast enough manually, thank you very much. :) This is usual. I hope that specific tools can make our lives occasionally a bit easier. Regards, Markus