> Thanks, We will change it to something like this: > In a function, for a local variable obtained by of_find_device_by_node() How do you think about another wording approach? 1. Precondition: It will be checked where the return value is stored from a call of the function “of_find_device_by_node”. 2. The source code search will be continued with … > Thank you, but a local variable is necessary. Would you like to take additional storage possibilities for a safer analysis approach into account? Is the restriction “local” really sufficient when such a pointer could be copied to other variables? >> Can it happen that on other function will perform the desired reference release? > > Thanks. > Because the information of this local variable is not passed to the external function, > this situation does not exist. Will copied pointers matter here? > But it's over 80 characters. Long string literals can be accepted because of error message search concerns around a tool like “grep”. >> Will any more advanced error diagnostics be eventually developed? > > Hello, we are just doing the practical work in this field. Are you aware of additional software design options from computer science and existing analysis tools? > We also hope that it can support cross-function/cross-file/data stream analysis > and other functions. This functionality will need further clarification. > We are also analyzing the principle and code implementation of coccinelle, > hoping to contribute a little. I am curious on how this situation will evolve further. Regards, Markus
