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
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
> 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
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
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
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.
> >>
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
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
