[Cocci] Determination for the absence of an option in a function call

[Cocci] Determination for the absence of an option in a function call

[SF Markus Elfring]

Hello,

I am working with the following specification in some scripts for the semantic
patch language.

?
 target = action(...);
?


This source code search pattern shows that a return value from a function call
should be stored somewhere. The concrete call is restricted by a selection of
function names. Such an approach is working to some degree when restrictions
on function call parameters can be omitted.

But a safer source code analysis requires to distinguish these parameters in
more detail.

1. How should be ensured that a specific option was not passed?

2. The parameter number becomes also relevant then.
   How should functions be split based on their signature?

Regards,
Markus

[Cocci] Determination for the absence of an option in a function call

[Julia Lawall]

On Sat, 17 Feb 2018, SF Markus Elfring wrote:

> Hello,
>
> I am working with the following specification in some scripts for the semantic
> patch language.
>
> ?
>  target = action(...);
> ?
>
>
> This source code search pattern shows that a return value from a function call
> should be stored somewhere. The concrete call is restricted by a selection of
> function names. Such an approach is working to some degree when restrictions
> on function call parameters can be omitted.
>
> But a safer source code analysis requires to distinguish these parameters in
> more detail.
>
> 1. How should be ensured that a specific option was not passed?
>
> 2. The parameter number becomes also relevant then.
>    How should functions be split based on their signature?

I don't understand the questions.  What do you mean by option?  A
command-line option of Coccinelle?  A particular argument of action?

For the second question, maybe you are looking for the following:

@r@
expression list[n] es;
@@

target = action(es)

Now r.n is the number of arguments to action.

julia

[Cocci] Determination for the absence of an option in a function call

[Julia Lawall]

On Sat, 17 Feb 2018, SF Markus Elfring wrote:

> >> But a safer source code analysis requires to distinguish these parameters in
> >> more detail.
> >>
> >> 1. How should be ensured that a specific option was not passed?
> >>
> >> 2. The parameter number becomes also relevant then.
> >>    How should functions be split based on their signature?
> >
> > I don't understand the questions.  What do you mean by option?
>
> Enumeration values (or preprocessor symbols) are often used for this kind
> of function parameters.
> Do you prefer the wording ?flag??
>
>
> > A command-line option of Coccinelle?
>
> Not in this clarification attempt.
>
>
> > A particular argument of action?
>
> Yes.
>
> I am working with the determination for memory allocation functions
> from Linux source files for a while.
> It matters in this software domain if the option ?__GFP_NOWARN? was applied
> (or not).

<+...__GFP_NOWARN...+> in the appropriate argument position.

>
>
> > For the second question, maybe you are looking for the following:
> >
> > @r@
> > expression list[n] es;
> > @@
> >
> > target = action(es)
> >
> > Now r.n is the number of arguments to action.
>
> This information can be useful for other analysis goals than what
> I have got in mind here.
> Each function name is usually connected with a specific argument count.
> This fact has got some consequences for the development of corresponding
> SmPL scripts.

I still have no idea what you are looking for here.

julia

[Cocci] Determination for the absence of an option in a function call

[Julia Lawall]

On Sat, 17 Feb 2018, SF Markus Elfring wrote:

> >> I am working with the determination for memory allocation functions
> >> from Linux source files for a while.
> >> It matters in this software domain if the option ?__GFP_NOWARN? was applied
> >> (or not).
> >
> > <+...__GFP_NOWARN...+> in the appropriate argument position.
>
> It is easy to check the presence of such an identifier.
> But I find it very challenging to determine (by script code)
> if it is actually not passed (as an option) in a function call.

It's not clear what you want.  You will have to send some examples.

>
>
> >> Each function name is usually connected with a specific argument count.
> >> This fact has got some consequences for the development of corresponding
> >> SmPL scripts.
> >
> > I still have no idea what you are looking for here.
>
> I imagine that SmPL disjunctions (or further SmPL rules) will be
> relevant to distinguish the known parameter numbers.
>
> How would you manage the information which of the parameters
> would get the argument ?gfp? (for example)?

You have to match the definition of the function to find out what
parameter position you are interested in.  If the function is defined in
another file you may need to use iteration.  See demos/iteration.cocci.

julia

[Cocci] Determination for the absence of an option in a function call

[Julia Lawall]

On Sat, 17 Feb 2018, SF Markus Elfring wrote:

> >> It is easy to check the presence of such an identifier.
> >> But I find it very challenging to determine (by script code)
> >> if it is actually not passed (as an option) in a function call.
> >
> > It's not clear what you want.
>
> Another try ?
>
>
> > You will have to send some examples.
>
> When we look at concrete Linux source code, we mostly see that
> the option ?__GFP_NOWARN? is just missing for a call of a function
> like ?devm_kmalloc?.
>
> An other analysis tool can show the information that such an identifier
> is referenced only in 207 files (from Linux 4.16-rc1).
>
> But how can the Coccinelle software help here to exclude these source
> code places from specific transformation attempts?

(
f(...,<+...__GFP_NOWARN...+>,...)
|
transformation
)

Alternatively,

@ok@
position p;
@@
f(...,<+...__GFP_NOWARN...+>,...)

@@
position p != ok.p;
@@
- f at p(...)
+ whatever

>
>
> >> How would you manage the information which of the parameters
> >> would get the argument ?gfp? (for example)?
> >
> > You have to match the definition of the function to find out what
> > parameter position you are interested in.
>
> It seems to be feasible to encode such knowledge for a small number
> of function names (in SmPL disjunctions or regular expressions).
>
> But how does the software situation look like when you would like
> to automate the search for interesting positions as much as possible?

My iteration suggestion covers this case.

julia

[Cocci] Determination for the absence of an option in a function call

[Julia Lawall]

> I guess that it covers only a part of the desired search automation.
> The generic handling of variations in parameter positions is
> more challenging, isn't it?

With iteration you can collect some information on one pass and use it on
another pass.  This is discussed in the following set of slides:
http://coccinelle.lip6.fr/papers/cocciwk4_talk2.pdf

julia

[Cocci] Handling of variations in function call parameters

[Julia Lawall]

On Sat, 17 Feb 2018, SF Markus Elfring wrote:

> >> I guess that it covers only a part of the desired search automation.
> >> The generic handling of variations in parameter positions is
> >> more challenging, isn't it?
> >
> > With iteration you can collect some information on one pass and use it on
> > another pass.  This is discussed in the following set of slides:
> > http://coccinelle.lip6.fr/papers/cocciwk4_talk2.pdf
>
> It would be nice if a function database will be usable.
> Database queries can group the involved function names to some degree.

You can write python code to do whatever you want.

julia

[Cocci] Determination for the absence of an option in a function call

[Julia Lawall]

On Sat, 17 Feb 2018, SF Markus Elfring wrote:

> > f(...,<+...__GFP_NOWARN...+>,...)
>
> Does this SmPL specification mean that the identifier can appear anywhere
> within the function call parameters?

Yes.

> Would it be acceptable for a risk level of false positives to omit
> the check for the really appropriate parameter position?

Up to you to see what happens.

julia

[Cocci] Determination for the absence of an option in a function call

[Julia Lawall]

On Sat, 17 Feb 2018, SF Markus Elfring wrote:

> >>> f(...,<+...__GFP_NOWARN...+>,...)
> >>
> >> Does this SmPL specification mean that the identifier can appear anywhere
> >> within the function call parameters?
> >
> > Yes.
> >
> >> Would it be acceptable for a risk level of false positives to omit
> >> the check for the really appropriate parameter position?
> >
> > Up to you to see what happens.
>
> Thanks for another clarification.
>
> Does it increase the chances to integrate any SmPL scripts
> for transformation of questionable error messages after
> failed memory allocations into a directory which you maintain?
>
> Which confidence categorisation would fit here?

Low.  The script has no idea whether the printed string is useful or not.

julia

[Cocci] Checking for questionable error messages after failed memory allocations

[Julia Lawall]

On Sat, 17 Feb 2018, SF Markus Elfring wrote:

> >> Which confidence categorisation would fit here?
> >
> > Low.
>
> May scripts with this view be integrated?

It's possible.  It depends on the benefit of the transformation provided.

> > The script has no idea whether the printed string is useful or not.
>
> This is a general data processing challenge. How will it influence
> the software situation further?

I have no idea what "it" refers to, nor "software situation".

Maybe you can identify some cases that are particularly likely to be
useless and only report on those.

julia

[Cocci] Checking for questionable error messages after failed memory allocations

[Julia Lawall]

On Sat, 17 Feb 2018, SF Markus Elfring wrote:

> >>>> Which confidence categorisation would fit here?
> >>>
> >>> Low.
> >>
> >> May scripts with this view be integrated?
> >
> > It's possible.
>
> Will the integration make more sense when the duplication of
> regular expressions for SmPL constraints can be avoided?

This point is completely irrelevant.

> > It depends on the benefit of the transformation provided.
>
> Should the benefit be clearer after I published hundreds of update
> suggestions for this change pattern?

Well, many people have rejected the patches as well.  And checkpatch
already highlights the issue.

julia