>>> Which data element should not get reassigned here (before a corresponding >>> null pointer check)? >>> >> >> Thank you for your comments. >> We did some experiments: >> +id = of_find_device_by_node@p1(x) >> +... when != e = id >> ... >> Or: >> ... >> + ... when != id = e >> >> The number of issuses found by these two methods is the same. This can be because these SmPL specifications share some source code search functionality. >> When != e = id achieves this behavior. > > They are the same because neither issue arises. You might not notice a difference from a specific source file selection so far. > I would have a hard time saying which one is more reasonable to test, I suggest to reconsider the interpretation of this software situation once more. > since both are extremely unlikely. I disagree to this view because two ellipses were intentionally specified in published SmPL scripts. So some software developers found these “special use cases” important enough. >> In addition, we feel that we should probably accept this patch first, I disagree to this imagination because I would prefer to integrate a source code variant without a bug (which was copied from a version on 2013-05-08 by Petr Strnad). https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/scripts/coccinelle/free/pci_free_consistent.cocci?id=f7b167113753e95ae61383e234f8d10142782ace#n12 I hope that nicer run time behaviour can become also relevant here. >> use it to find more memory leaks, and solve the actual problems in the kernel code. Your are not hindered to achieve specific software improvements with evolving development approaches while the clarification and the final integration of useful scripts for the semantic patch language can take a bit longer. >> As for the patch itself, we can continue to pursue perfect in the process >> of using it to solve practical problems. I am curious on how your attention will evolve further for the corresponding software correctness. 1. How much will you care for the order of identifiers within the application of SmPL assignment exclusions? 2. Would you like to take additional data type restrictions into account? Regards, Markus
