On Sat, 16 Feb 2019, [email protected] wrote:
> > > 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 …
>
> Thanks.
> This is more rigorous, we will follow your advice
>
> > > 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?
>
> We may be able to handle this situation:
> +id = of_find_device_by_node@p1(x)
> ...
> + when != e1 = (T)id
> + when != e1 = &id->dev
> + when != e1 = get_device(&id->dev)
This looks good. To be double sure, you can put (T)(&id->dev) in the
second case.
When you have a chance please send the revised version. As long as I
don't see that it is giving many false positives, I will accept it. We
don't need perfection. We need more to eliminate the memory leaks.
julia
>
> > > But it's over 80 characters.
> >
> > Long string literals can be accepted because of error message search concerns
> > around a tool like “grep”.
>
> Thanks.
> We will follow your advice
>
> >> 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 use the commercial software klockwork, which will also find errors in the code,
> but a lot of false positives.
>
> Regards,
> Wen
Actually, upon reflection, I don't like the if (...) solution. if (id !=
NULL) would be better. This will also check for if (id). If having such
an explicit test results in false positives, the semantic patch can be
revised. But it is better than if (...), which allow anything at all, and
could miss cases where the free should happen, but does not.
julia
> We don't need perfection.
I guess that you noticed in the meantime that I dare to propose
more software development efforts in such a direction.
> We need more to eliminate the memory leaks.
Will this view evolve into further helpful and constructive clarifications?
Regards,
Markus
Hi,
On Sat, Feb 16, 2019 at 09:57:54AM +0100, Markus Elfring wrote:
> > We don't need perfection.
>
> I guess that you noticed in the meantime that I dare to propose
> more software development efforts in such a direction.
Yes, this is noticable. It is your choice, however, other people may
have their reasons for other choices...
> > We need more to eliminate the memory leaks.
... like this one.
> Will this view evolve into further helpful and constructive clarifications?
Given my above, what is the evaluation of the same question to yourself?
Regards,
Wolfram
>>> We don't need perfection.
>>
>> I guess that you noticed in the meantime that I dare to propose
>> more software development efforts in such a direction.
>
> Yes, this is noticable.
I am curious then if remaining change suggestions will be picked up
by more software developers and reviewers.
> It is your choice, however, other people may have their reasons
> for other choices...
Yes, of course.
>>> We need more to eliminate the memory leaks.
>
> ... like this one.
>
>> Will this view evolve into further helpful and constructive clarifications?
>
> Given my above, what is the evaluation of the same question to yourself?
* I hope that my contributions can improve the situation also
for this software area.
* Existing development tools will evolve further as usual.
Regards,
Markus