>> * Do we agree that a proper size determination is essential for every >> condition in the discussed SmPL rules together with forwarding >> this information? > > No. I don't mind a few false positives. I have got other source code analysis expectations there. This SmPL script contains the tag “Confidence: High”. > The user can look at the answer and see if it is a false positive or not. The situation is questionable because of a specific software design detail. Unsafe source code search patterns could be stored under other script names (or even different directories). How do you think about to move the SmPL code (which I proposed for deletion) to another script if you would insist to preserve it? > Furthermore, I told you how to address this function so that the size > issue would be taken care of. You offered another bit of information. I find your interpretation of this aspect also unclear at the moment. > That is the patch that I would accept. Are there any better development solutions left over? >> * How can a name be ever relevant (within the published SmPL approach) >> for a function when it was designed in the way that it should generally >> work without a size parameter? > > No idea what this means. I am trying again to resolve corresponding communication difficulties. Thus I suggest to take another look at the following SmPL code fragment. … kmalloc_node(E1, ...)\|kmem_cache_alloc(...)\|kmem_alloc(E1, ...)\| … * memset((T2)x,0,E1); … How many constraints should be considered for function parameters here? Regards, Markus -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
