Re: [v5] coccinelle: semantic code search for missingput_device()

Re: [v5] coccinelle: semantic code search for missingput_device()

[Julia Lawall]

[-- Attachment #1: Type: text/plain, Size: 1883 bytes --]



On Sat, 16 Feb 2019, wen.yang99@zte.com.cn 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

Re: [v5] coccinelle: semantic code search for missingput_device()

[Julia Lawall]

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

Re: [v5] coccinelle: semantic code search for missingput_device()

[Markus Elfring]

> 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

Re: [Cocci] [v5] coccinelle: semantic code search for missingput_device()

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 603 bytes --]

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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [Cocci] [v5] coccinelle: semantic code search for missingput_device()

[Markus Elfring]

>>> 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

Re: [v5] coccinelle: semantic code search for missingput_device()

[Julia Lawall]

[-- Attachment #1: Type: text/plain, Size: 1838 bytes --]



On Sat, 16 Feb 2019, Markus Elfring 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 …
>
>
> > 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?

I've lost track of the original semantic patch, but perhaps it needs a

when != e1 = e

julia

>
>
> >> 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
>

Re: [v5] coccinelle: semantic code search for missingput_device()

[Markus Elfring]

> 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