2019-05-15 09:42:45

by Markus Elfring

[permalink] [raw]
Subject: Re: [3/3] Coccinelle: pci_free_consistent: Extend when constraints for two SmPL ellipses

>>> On the other hand, I do care about causing false negatives.
>>
>> Do you find the missing warning after the addition of such an exclusion
>> specification interesting?
>
> I already suggested how to improve the code.

I find that the idea “e2->fld” needs further clarification.
Such a SmPL specification will be resolved also to an expression,
won't it?

I guess that it can fit better to other analysis approaches.
Will any script variants become more interesting?

Is it still unclear which detail (besides the added SmPL filter)
will hinder the warning display for Wen's test case?

Regards,
Markus


2019-05-15 10:21:56

by Julia Lawall

[permalink] [raw]
Subject: Re: [3/3] Coccinelle: pci_free_consistent: Extend when constraints for two SmPL ellipses



On Wed, 15 May 2019, Markus Elfring wrote:

> >>> On the other hand, I do care about causing false negatives.
> >>
> >> Do you find the missing warning after the addition of such an exclusion
> >> specification interesting?
> >
> > I already suggested how to improve the code.
>
> I find that the idea “e2->fld” needs further clarification.
> Such a SmPL specification will be resolved also to an expression,
> won't it?

Saving in a local variable doesn't impact the need to free the object. A
field is the most obvious case where the object may not need freeing. But
there are many expressions that e2->fld will not match.

julia

2019-05-15 11:56:17

by Markus Elfring

[permalink] [raw]
Subject: Re: [3/3] Coccinelle: pci_free_consistent: Extend when constraints for two SmPL ellipses



Am 15.05.19 um 12:19 schrieb Julia Lawall:
>
>
> On Wed, 15 May 2019, Markus Elfring wrote:
>
>>>>> On the other hand, I do care about causing false negatives.
>>>>
>>>> Do you find the missing warning after the addition of such an exclusion
>>>> specification interesting?
>>>
>>> I already suggested how to improve the code.
>>
>> I find that the idea “e2->fld” needs further clarification.
>> Such a SmPL specification will be resolved also to an expression,
>> won't it?
>
> Saving in a local variable doesn't impact the need to free the object.

I suggest to reconsider this view.

Would we like to introduce additional case distinctions for the handling
of reassignments to local variables (as shown in Wen's test case)?


> A field is the most obvious case where the object may not need freeing.

A corresponding resource release should probably be performed by
an other function then.


> But there are many expressions that e2->fld will not match.

Data structure members can eventually belong also to a local variable.
Would they become relevant for further SmPL exclusion specifications?

Regards,
Markus