>> The uncertainty around the partly (un)documented software behaviour
>> for SmPL when constraints makes it unclear then if the presented
>> source code place should finally be treated as a false positive.
Will it be easier to clarify this open issue based on a smaller
source code example?
>> The uncertainty around the partly (un)documented software behaviour
>> for SmPL when constraints makes it unclear then if the presented
>> source code place should finally be treated as a false positive.
Are you going to do anything more for this concern?
>> Should it have been excluded
On Sat, 19 Oct 2019, Markus Elfring wrote:
> >> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/gpu/drm/arm/display/komeda/komeda_dev.c?id=c4b9850b3676869ac0def5885d781d17f64b3a86#n222
> >>
> >> …
> >> @@ -222,… @@ struct komeda_dev *komeda_dev_create(str
> >>
>
>> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/gpu/drm/arm/display/komeda/komeda_dev.c?id=c4b9850b3676869ac0def5885d781d17f64b3a86#n222
>>
>> …
>> @@ -222,… @@ struct komeda_dev *komeda_dev_create(str
>>
>> clk_prepare_enable(mdev->aclk);
>>
>> -
On Sat, 19 Oct 2019, Markus Elfring wrote:
> > Now I would like to point another analysis concern out.
>
> You informed me about an approach for the usage of when constraints
> with the semantic patch language in the following way according to
> the discussion topic “Detection of unused
> Now I would like to point another analysis concern out.
You informed me about an approach for the usage of when constraints
with the semantic patch language in the following way according to
the discussion topic “Detection of unused function return values”
(on 2011-12-11).
“…
Rule r checks
>> @display@
>> expression* x, y;
>> @@
>> *y = (x)(...);
>> ... when != y
>
> device_link_add does not look like a function pointer.
Can a known function name be equivalent to a function pointer?
See also:
https://en.cppreference.com/w/c/language/pointer#Pointers_to_functions
On Fri, 18 Oct 2019, Markus Elfring wrote:
> > expression *y;
>
> This specific information is interesting.
>
> It was mentioned that further software development concerns
> can occur around the possible application of function pointers.
> Now I would like to point another analysis concern out.
> expression *y;
This specific information is interesting.
It was mentioned that further software development concerns
can occur around the possible application of function pointers.
Now I would like to point another analysis concern out.
The following SmPL search approach does not present the
> Function pointers certainly have a return type,
This is fine as usual.
> but the return type could be int.
This can also happen.
But I would like to specify the restriction for a known pointer variant
at this place.
Regards,
Markus
___
Cocci
On Fri, 18 Oct 2019, Markus Elfring wrote:
> >> Will the distinction be improved for the safe usage of function pointers
> >> also together with the semantic patch language?
> >
> > I don't see any reason why declaring x as expression *x; should imply
> > anything about the type of the value
>> Will the distinction be improved for the safe usage of function pointers
>> also together with the semantic patch language?
>
> I don't see any reason why declaring x as expression *x; should imply
> anything about the type of the value returned by a function pointer.
Function pointers have
On Fri, 18 Oct 2019, Markus Elfring wrote:
> >> The metavariable “x” can be restricted to a pointer expression.
> >> But does such specification ensure also that the function pointer is
> >> connected
> >> with a pointer return type?
> >
> > No.
>
> Thanks for another clarification.
>
> Will
>> The metavariable “x” can be restricted to a pointer expression.
>> But does such specification ensure also that the function pointer is
>> connected
>> with a pointer return type?
>
> No.
Thanks for another clarification.
Will the distinction be improved for the safe usage of function
> In int *i; there is no pointer dereference.
Thanks for this clarification.
The semantic patch language syntax needs a different interpretation
of the desired meaning.
How do you think about to add the mentioned detail to the SmPL manual?
> Y should match a pointer-typed expression.
This
On Fri, 18 Oct 2019, Markus Elfring wrote:
> >> Which would be a simple way to find only calls of functions
> >> which have got a pointer return type?
> >
> > expression *y;
>
> I have got understanding difficulties with this SmPL variable specification.
> I (as a C programmer) would tend to
>> Which would be a simple way to find only calls of functions
>> which have got a pointer return type?
>
> expression *y;
I have got understanding difficulties with this SmPL variable specification.
I (as a C programmer) would tend to interpret an asterisk before
an expression as a pointer
On Fri, 18 Oct 2019, Markus Elfring wrote:
> > Why not just
>
> @display@
> expression x, y;
> @@
> *y = (x)(...);
> ... when != y
>
>
> It seems that such a source code search approach has got a high probability
> for false positives, doesn't it?
> Thus I am trying again to restrict it in
> Why not just
@display@
expression x, y;
@@
*y = (x)(...);
... when != y
It seems that such a source code search approach has got a high probability
for false positives, doesn't it?
Thus I am trying again to restrict it in reasonable ways.
Which would be a simple way to find only calls of
19 matches
Mail list logo
