> +@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 triggers challenges for safe data flow handling.
the semantic patch language supports search specifications for
the exclusion of specific assignments.
Does this SmPL code contain a questionable order for the source
and target metavariables?
Can the following variant be more appropriate?
+ ... when != id = e
> +if (id == NULL || ...) { ... return ...; }
> +... when != put_device(&id->dev)
> + when != platform_device_put(id)
> + when != of_dev_put(id)
> + when != if (id) { ... put_device(&id->dev) ... }
> + when != e1 = (T)id
Would you like to avoid that the return value from the shown function call
gets overwritten in the variable before it was used once at least
(when a bit of extra C code is tolerated before a null pointer check)?
Regards,
Markus
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 also for
> another implementation detail.
> Source code analysis triggers challenges for safe data flow handling.
> the semantic patch language supports search specifications for
> the exclusion of specific assignments.
>
> Does this SmPL code contain a questionable order for the source
> and target metavariables?
> Can the following variant be more appropriate?
>
> + ... when != id = e
This is possible, but I think unlikely.
>
>
> > +if (id == NULL || ...) { ... return ...; }
> > +... when != put_device(&id->dev)
> > + when != platform_device_put(id)
> > + when != of_dev_put(id)
> > + when != if (id) { ... put_device(&id->dev) ... }
> > + when != e1 = (T)id
>
> Would you like to avoid that the return value from the shown function call
> gets overwritten in the variable before it was used once at least
> (when a bit of extra C code is tolerated before a null pointer check)?
Indeed there should be a put then too, but again, it seems unlikely.
julia
>
> Regards,
> Markus
>
>>> +@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 triggers challenges for safe data flow handling.
>> the semantic patch language supports search specifications for
>> the exclusion of specific assignments.
>>
>> Does this SmPL code contain a questionable order for the source
>> and target metavariables?
>> Can the following variant be more appropriate?
>>
>> + ... when != id = e
>
> This is possible, but I think unlikely.
Would you dare to interpret my update suggestion (reordering of two identifiers)
as a required SmPL script correction?
Regards,
Markus
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 also for
> >> another implementation detail.
> >> Source code analysis triggers challenges for safe data flow handling.
> >> the semantic patch language supports search specifications for
> >> the exclusion of specific assignments.
> >>
> >> Does this SmPL code contain a questionable order for the source
> >> and target metavariables?
> >> Can the following variant be more appropriate?
> >>
> >> + ... when != id = e
> >
> > This is possible, but I think unlikely.
>
> 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. Both are needed.
And, no I don't consider it to be a required suggestion. In practice,
reassigning such a variable is very unlikely.
julia
>> 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 you would insist on the specification of such an assignment exclusion
for a SmPL ellipsis:
Can we agree on a correct order?
> And, no I don't consider it to be a required suggestion.
Have we got a different view about an implementation detail at this place?
> In practice, reassigning such a variable is very unlikely.
This can be.
Regards,
Markus
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 version
> of this evolving SmPL script.
>
>
> > Both are needed.
>
> 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. There is no correct order. Each order expresses
something different. The order that is currently in the semantic patch is
the one that is more likely in practice.
julia
>
>
> > And, no I don't consider it to be a required suggestion.
>
> Have we got a different view about an implementation detail at this place?
>
>
> > In practice, reassigning such a variable is very unlikely.
>
> This can be.
>
> Regards,
> Markus
>
>> 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 view here.
> Each order expresses something different.
I agree to this information.
> The order that is currently in the semantic patch is the one
> that is more likely in practice.
Please check once more.
…
+@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 behaviour?
Regards,
Markus
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 is no correct order.
>
> I have got an other software development view here.
>
>
> > Each order expresses something different.
>
> I agree to this information.
>
>
> > The order that is currently in the semantic patch is the one
> > that is more likely in practice.
>
> Please check once more.
>
> …
> +@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 behaviour?
The desired behavior is to check whether the allocated value is saved in
some other variable (typically a structure field) and thus it doesn't need
to be freed just because the original local variable goes out of scope at
the end of the function. when != e = id achieves this behavior.
julia
>> …
>> +@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 behaviour?
>
> The desired behavior is to check whether the allocated value is saved in
> some other variable (typically a structure field) and thus it doesn't need
> to be freed just because the original local variable goes out of scope at
> the end of the function.
I find this description reasonable to some degree.
(I am unsure if a programmer would like to fiddle with return value storage
in a data structure member from a local variable.)
> 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 imagine
that there is an intersection for the source code match possibility.
But one was intentionally restricted to the kind “local idexpression” so far.
Which data element should not get reassigned here (before a corresponding
null pointer check)?
Regards,
Markus