> Do you have any other questions?
I would like to point another aspect out for further development considerations.
The initial assignment targets are (id)expressions in the discussed analysis
approach so far.
Would you like to care also for value (or pointer) initialisations by resource
>> Will corrections become relevant for specifications in (assignment)
>> exclusions
>> of the second SmPL ellipsis in the discussed script?
>
> Let's do some experiments with the code in the current kernel.
It seems that you provided additional information for the adjustment
of when
> Do you have any other questions?
Obviously, yes.
I am curious if this development discussion and code review will trigger
further software adjustments.
I guess that you will need additional time to reconsider specific items
from recent feedback.
Will corrections become relevant for
>> Although we have tested these two methods in the existing kernel code,
>> considering the evolution of the kernel code, these special cases may occur,
>> so we are willing to take them into account.
>> We plan to modify the code like this:
>>
>> id = of_find_device_by_node@p1(x)
>> -... when
On Tue, 19 Feb 2019, wen.yan...@zte.com.cn wrote:
> > > I would have a hard time saying which one is more reasonable to test,
> > I suggest to reconsider the interpretation of this software situation once
> > more.
> > > since both are extremely unlikely.
> > I disagree to this view because
>> Which data element should not get reassigned here (before a corresponding
>> null pointer check)?
>>
>
> Thank you for your comments.
> We did some experiments:
> +id = of_find_device_by_node@p1(x)
> +... when != e = id
> ...
> Or:
> ...
> + ... when != id = e
>
> The number of issuses found by
>>> Which data element should not get reassigned here (before a corresponding
>>> null pointer check)?
>>>
>>
>> Thank you for your comments.
>> We did some experiments:
>> +id = of_find_device_by_node@p1(x)
>> +... when != e = id
>> ...
>> Or:
>> ...
>> + ... when != id = e
>>
>> The number of
On Mon, 18 Feb 2019, wen.yan...@zte.com.cn wrote:
> > > when != e = id achieves this behavior.
> >
> > I can not agree to this view completely because of the meaning that is
> > connected
> > with these variable identifiers.
> >
> > Both metavariables share the kind “expression”. So I can
>> …
>> +@search exists@
>> +local idexpression id;
>> +expression x,e,e1;
>> +position p1,p2;
>> …
>> +@@
>> +
>> +id = of_find_device_by_node@p1(x)
>> +... when != e = id
>> …
>>
>> Or:
>>
>> …
>> + ... when != id = e
>> …
>>
>>
>> Which SmPL specification will achieve the desired software
On Sun, 17 Feb 2019, Markus Elfring wrote:
> >> If you would insist on the specification of such an assignment exclusion
> >> for a SmPL ellipsis:
> >> Can we agree on a correct order?
> >
> > I don't get your point.
>
> I propose to take another closer look at a bit of SmPL code.
>
>
> > There
>> If you would insist on the specification of such an assignment exclusion
>> for a SmPL ellipsis:
>> Can we agree on a correct order?
>
> I don't get your point.
I propose to take another closer look at a bit of SmPL code.
> There is no correct order.
I have got an other software development
On Sun, 17 Feb 2019, Markus Elfring wrote:
> >> Would you dare to interpret my update suggestion (reordering of two
> >> identifiers)
> >> as a required SmPL script correction?
> >
> > I didn't suggest to reorder anything.
>
> This is obvious according to your acknowledgement for the sixth
>> Would you dare to interpret my update suggestion (reordering of two
>> identifiers)
>> as a required SmPL script correction?
>
> I didn't suggest to reorder anything.
This is obvious according to your acknowledgement for the sixth version
of this evolving SmPL script.
> Both are needed.
If
On Sun, 17 Feb 2019, Markus Elfring wrote:
> >>> +@search exists@
> >>> +local idexpression id;
> >>> +expression x,e,e1;
> >>> +position p1,p2;
> >>> +type T,T1,T2;
> >>> +@@
> >>> +
> >>> +id = of_find_device_by_node@p1(x)
> >>> +... when != e = id
> >>
> >> I suggest to increase your
>>> +@search exists@
>>> +local idexpression id;
>>> +expression x,e,e1;
>>> +position p1,p2;
>>> +type T,T1,T2;
>>> +@@
>>> +
>>> +id = of_find_device_by_node@p1(x)
>>> +... when != e = id
>>
>> I suggest to increase your software development attention also for
>> another implementation detail.
On Sun, 17 Feb 2019, Markus Elfring wrote:
> > +@search exists@
> > +local idexpression id;
> > +expression x,e,e1;
> > +position p1,p2;
> > +type T,T1,T2;
> > +@@
> > +
> > +id = of_find_device_by_node@p1(x)
> > +... when != e = id
>
> I suggest to increase your software development attention
> +@search exists@
> +local idexpression id;
> +expression x,e,e1;
> +position p1,p2;
> +type T,T1,T2;
> +@@
> +
> +id = of_find_device_by_node@p1(x)
> +... when != e = id
I suggest to increase your software development attention also for
another implementation detail.
Source code analysis
> But please also refer to the examples of coccinelle, such as:
> http://coccinelle.lip6.fr/rules/kmalloc.html
> and
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/scripts/coccinelle/free/pci_free_consistent.cocci
These scripts for the semantic patch language show some
> In a function, for a local variable obtained by of_find_device_by_node(),
I got a software understanding where such a variable can not be obtained
from this function call.
The return value (like a pointer in this use case) can be stored there.
> v6:
> - to be double sure, replace >dev with
On Sat, 16 Feb 2019, Wen Yang wrote:
> The of_find_device_by_node() takes a reference to the underlying device
> structure, we should release that reference.
> The implementation of this semantic code search is:
> In a function, for a local variable obtained by of_find_device_by_node(),
> a,
20 matches
Mail list logo
