Re: [Cocci] might be bug report, breaking up of a comment

[Julia Lawall]

On Sat, 17 Feb 2018, Robert Larice wrote:

> Julia Lawall  writes:
>
> > On Sat, 17 Feb 2018, Robert Larice wrote:
> >
> >> Hello,
> >>
> >>   attached is a small example which seems to
> >> break up a comment line,
> >> thus commenting out following lines.
> >>
> >>   Please look at the "long reuse" line
> >> which will have an open comment when spatch is run,
> >> thus commenting out the following "struct line *options"
> >
> > I also see this undesriable behavior.  Thanks for the report.
> >
> > julia
>
> grepping a bit in the source code I found this:
>   cpp_eat_until_nl
> perhaps in the vicinity of the issue.
>
> and there is this comment somewhere:
>
> (* cpp recognize C comments, so when #define xx (yy) /* comment \n ... */
>  * then he has already erased the /* comment. So:
>  * - dont eat the start of the comment otherwise afterwards we are in the 
> middle
>  *   of a comment and so will problably get a parse error somewhere.
>  * - have to recognize comments in cpp_eat_until_nl.
>  *)

Thanks for the help, but that's not it at all.  The problem is in the
function get_indent in the file parsing_c/unparse_c.ml.  I'll try to fix
it tomorrow.

julia
___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] might be bug report, breaking up of a comment

[Robert Larice]

Julia Lawall  writes:

> On Sat, 17 Feb 2018, Robert Larice wrote:
>
>> Hello,
>>
>>   attached is a small example which seems to
>> break up a comment line,
>> thus commenting out following lines.
>>
>>   Please look at the "long reuse" line
>> which will have an open comment when spatch is run,
>> thus commenting out the following "struct line *options"
>
> I also see this undesriable behavior.  Thanks for the report.
>
> julia

grepping a bit in the source code I found this:
  cpp_eat_until_nl
perhaps in the vicinity of the issue.

and there is this comment somewhere:

(* cpp recognize C comments, so when #define xx (yy) /* comment \n ... */
 * then he has already erased the /* comment. So:
 * - dont eat the start of the comment otherwise afterwards we are in the middle
 *   of a comment and so will problably get a parse error somewhere.
 * - have to recognize comments in cpp_eat_until_nl.
 *)

___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] might be bug report, breaking up of a comment

[Julia Lawall]

On Sat, 17 Feb 2018, Robert Larice wrote:

> Hello,
>
>   attached is a small example which seems to
> break up a comment line,
> thus commenting out following lines.
>
>   Please look at the "long reuse" line
> which will have an open comment when spatch is run,
> thus commenting out the following "struct line *options"

I also see this undesriable behavior.  Thanks for the report.

julia
___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

[Cocci] might be bug report, breaking up of a comment

[Robert Larice]

Hello,

  attached is a small example which seems to
break up a comment line,
thus commenting out following lines.

  Please look at the "long reuse" line
which will have an open comment when spatch is run,
thus commenting out the following "struct line *options"

Best Regards,
  Robert Larice

// (compile "spatch --sp-file ex5.cocci ex5.c")

// a might be bug report

// in ex5.c there is a comment spawning to lines
// this patch seems to open up this comment (behind "long reuse"),
//   dropping its second half,
//   thus effectively commenting out following lines

@r2@
@@
- struct line
+ struct card
void
foobarbazi(
struct line *deck, /*in: the spice deck */
long reuse,/*in: TRUE if called from runcoms2.c com_rset,
 FALSE if called from inp_spsource() */
struct line *options   /*in: all .option lines from deck */
)
{
return 42;
}
___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [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
___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [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 mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [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 mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [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 mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [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 mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [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 mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [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@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 mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [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 mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [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 mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [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 mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

[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 mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] Clarification for scripted SmPL constraints

[SF Markus Elfring]

>> Which parameters should be passed to the selected function?
> 
> You can always pass the declared metavariable.

I have got special imaginations for convenient parameter passing
in such an use case.


> You can put a comma-separated list of inherited metavariables

Do you suggest that a dependency on metavariable inheritance is required?


> (r.a, r.b, ...) between the parentheses, and then use a, b, etc in the script 
> code.

I would appreciate if the needed data would be directly available for
the predicate function (without repeating variable names).


> If there are no disjunctions in the rule and if the declared metavariable
> is no seprated by ... from a metavariable previously declared in the same 
> rule,
> then the latter variable can be included in the () as well, with no rule
> name, and then used in the script code.

I find this condition hard to understand at the moment.

Regards,
Markus
___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] please help me with a failing match

[Robert Larice]

Julia Lawall  writes:

> On Sat, 17 Feb 2018, Robert Larice wrote:
>
>> Julia Lawall  writes:
>>
>> > On Sat, 10 Feb 2018, Robert Larice wrote:
>> >
>> >> Julia Lawall  writes:
>> >>
>> >> > On Sat, 10 Feb 2018, Robert Larice wrote:
>> >> >
>> >> >> Dear People,
>> >> >>
>> >> >>   I'm completely new here.
>> >> >>
>> >> >>   Attached is a small piece of .c and a .cocci file.
>> >> >>   There is a "return 41;" in both files, commented out.
>> >> >>   If I uncomment this "return 41;" in both files then
>> >> >> spatch will not match the pieces any more.
>> >> >>
>> >> >>   Could you please help me to undertand and circumvent this issue ?
>> >> >
>> >> > I have not noticed this problem before, but I suspect that it is due to
>> >> > the fact that Coccinelle is matching the control-flow path and not the
>> >> > abstract syntax tree. In a control-flow graph, nothing follows a return.
>> >> >
>> >> > julia
>> >>
>> >> Thank You,
>> >> I tried to sneak around the problem with a second "rule" which
>> >>   translates "return 42" to "auxiliary(42)".
>> >> My intention was to first change the source in such a way
>> >>   that the "control-flow" graph does not end at the "return",
>> >> and then hope that the second (accordingly modified) rule would
>> >>   match.
>> >> This didn't work, I assume I would have to express the idea of
>> >>   first applying the first rule
>> >> then to rebuild the control-flow graph
>> >>   then try the second rule.
>> >>   (and finally undo the changes of the first rule in a third rule)
>> >> I can not force "rebuild" without invoking spatch myself a second time.
>> >
>> > If you change all the returns to something else and then match your
>> > pattern, and then change them it should work.
>> >
>> >>
>> >> ---
>> >> I'm a bit of a maintainer for the "ngspice" project, which has a vast
>> >>   amount of very old files, and lots of semi duplicated stuff often crying
>> >>   for a thourough hair wash,
>> >> stumbled over this intresting tool, and am tying it for a certain
>> >>   rewrite I'm currently busy with.
>> >
>> > OK,feel free to ask more questions if you run into further issues.
>> >
>> > julia
>>
>> Hello,
>>
>>   Thank you for your help. I've four or five .cocci files now which
>> do the job at hand for ngspice quite well. The rewrite of return
>> to something else with two times invocation of spatch did work.
>>   Then I found another simpler way. So thats done.
>>
>>   Playing around, trying to better understand what it means
>> to have more than one rule, their interaction etc ..
>> I came to the attached example.
>>   Here I have basically tried to remove the whole body of a function
>> iff the function matches two other @rules@
>>   It seems to work if I use the '*' notation, but doesnt if I use
>> '+/-'
>>   Can you give me a hint which helps me to understand this ?
>
> For -+, Coccinelle requires that all control-flow paths from the starting
> point of the match match the complete rule. So for example a() ... b()
> would match the following:
>
> a();
> if (x)
>   b();
> else b();
>
> For *, it only requires the existence of such a path.
>
> If you have a -+ somewhere in the semantic patch, then all rules use the
> forall semantics.  If you have a * somewhere in the semantic patch, then
> all rules use the exists semantics.
>
> In your rule r2, you have ... Label: but this label is not reached on the
> execution path that ends in return 1.  When you have -+ somewhere in the
> semantic patch this rule is not satisfied.
>
> If you want to change the default for a rule, you can add exists for
> forall to the rule header, or put when exists or when forall on the ...
>
> julia

Thank You very much,

The behaviour, and what I have to do to fix it, is perfectly clear now,

Regards,
Robert
___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] Clarification for scripted SmPL constraints

[Julia Lawall]

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

> >> I would appreciate if the place for the desired predicate will be better 
> >> explained.
> >>
> >> May they refer to a predefined function?
> >
> > When you write eg
> >
> > identifier x : script:python(...) { ... };
> >
> > or
> >
> > identifier x : script:ocaml(...) { ... };
> >
> > Between the { ... } you can put any code that you could put in a python or
> > ocaml script, respectively.
>
> Which parameters should be passed to the selected function?

You can always pass the declared metavariable.  You can put a
comma-separated list of inherited metavariables (r.a, r.b, ...) between
the parentheses, and then use a, b, etc in the script code.  If there are
no disjunctions in the rule and if the declared metavariable is no
seprated by ... from a metavariable previously declared in the same rule,
then the latter variable can be included in the () as well, with no rule
name, and then used in the script code.

julia
___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] Avoiding code duplication for SmPL constraints

[Julia Lawall]

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

> >> Now I am looking again for further possibilities to avoid corresponding
> >> code duplication.
> >>
> >> * Scripted constraints might be a design option.
> >>   Unfortunately, I find the documentation for this functionality still 
> >> incomplete.
> >
> > What information do you find to be lacking?
>
> I would appreciate if the place for the desired predicate will be better 
> explained.
>
> May they refer to a predefined function?

When you write eg

identifier x : script:python(...) { ... };

or

identifier x : script:ocaml(...) { ... };

Between the { ... } you can put any code that you could put in a python or
ocaml script, respectively.

julia
___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] Avoiding code duplication for SmPL constraints

[Julia Lawall]

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

> Hello,
>
> Constraints can be specified for metavariables of the semantic patch language.
> I noticed that they can trigger software maintenance challenges
> when bigger specifications are repeated in some SmPL rules.
> Now I am looking again for further possibilities to avoid corresponding
> code duplication.
>
> * Scripted constraints might be a design option.
>   Unfortunately, I find the documentation for this functionality still 
> incomplete.

What information do you find to be lacking?

> * I imagine that it would nice if constraints could be set by programming 
> script
>   rules at a single place.

The simplest thing to do is to define a function in the initialize part of
the semantic patch, and then call that function in the constraints as
needed.

julia
___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

[Cocci] Avoiding code duplication for SmPL constraints

[SF Markus Elfring]

Hello,

Constraints can be specified for metavariables of the semantic patch language.
I noticed that they can trigger software maintenance challenges
when bigger specifications are repeated in some SmPL rules.
Now I am looking again for further possibilities to avoid corresponding
code duplication.

* Scripted constraints might be a design option.
  Unfortunately, I find the documentation for this functionality still 
incomplete.

* I imagine that it would nice if constraints could be set by programming script
  rules at a single place.

Regards,
Markus
___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] please help me with a failing match

[Julia Lawall]

On Sat, 17 Feb 2018, Robert Larice wrote:

> Julia Lawall  writes:
>
> > On Sat, 10 Feb 2018, Robert Larice wrote:
> >
> >> Julia Lawall  writes:
> >>
> >> > On Sat, 10 Feb 2018, Robert Larice wrote:
> >> >
> >> >> Dear People,
> >> >>
> >> >>   I'm completely new here.
> >> >>
> >> >>   Attached is a small piece of .c and a .cocci file.
> >> >>   There is a "return 41;" in both files, commented out.
> >> >>   If I uncomment this "return 41;" in both files then
> >> >> spatch will not match the pieces any more.
> >> >>
> >> >>   Could you please help me to undertand and circumvent this issue ?
> >> >
> >> > I have not noticed this problem before, but I suspect that it is due to
> >> > the fact that Coccinelle is matching the control-flow path and not the
> >> > abstract syntax tree. In a control-flow graph, nothing follows a return.
> >> >
> >> > julia
> >>
> >> Thank You,
> >> I tried to sneak around the problem with a second "rule" which
> >>   translates "return 42" to "auxiliary(42)".
> >> My intention was to first change the source in such a way
> >>   that the "control-flow" graph does not end at the "return",
> >> and then hope that the second (accordingly modified) rule would
> >>   match.
> >> This didn't work, I assume I would have to express the idea of
> >>   first applying the first rule
> >> then to rebuild the control-flow graph
> >>   then try the second rule.
> >>   (and finally undo the changes of the first rule in a third rule)
> >> I can not force "rebuild" without invoking spatch myself a second time.
> >
> > If you change all the returns to something else and then match your
> > pattern, and then change them it should work.
> >
> >>
> >> ---
> >> I'm a bit of a maintainer for the "ngspice" project, which has a vast
> >>   amount of very old files, and lots of semi duplicated stuff often crying
> >>   for a thourough hair wash,
> >> stumbled over this intresting tool, and am tying it for a certain
> >>   rewrite I'm currently busy with.
> >
> > OK,feel free to ask more questions if you run into further issues.
> >
> > julia
>
> Hello,
>
>   Thank you for your help. I've four or five .cocci files now which
> do the job at hand for ngspice quite well. The rewrite of return
> to something else with two times invocation of spatch did work.
>   Then I found another simpler way. So thats done.
>
>   Playing around, trying to better understand what it means
> to have more than one rule, their interaction etc ..
> I came to the attached example.
>   Here I have basically tried to remove the whole body of a function
> iff the function matches two other @rules@
>   It seems to work if I use the '*' notation, but doesnt if I use
> '+/-'
>   Can you give me a hint which helps me to understand this ?

For -+, Coccinelle requires that all control-flow paths from the starting
point of the match match the complete rule. So for example a() ... b()
would match the following:

a();
if (x)
  b();
else b();

For *, it only requires the existence of such a path.

If you have a -+ somewhere in the semantic patch, then all rules use the
forall semantics.  If you have a * somewhere in the semantic patch, then
all rules use the exists semantics.

In your rule r2, you have ... Label: but this label is not reached on the
execution path that ends in return 1.  When you have -+ somewhere in the
semantic patch this rule is not satisfied.

If you want to change the default for a rule, you can add exists for
forall to the rule header, or put when exists or when forall on the ...

julia
___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] please help me with a failing match

[Robert Larice]

Julia Lawall  writes:

> On Sat, 10 Feb 2018, Robert Larice wrote:
>
>> Julia Lawall  writes:
>>
>> > On Sat, 10 Feb 2018, Robert Larice wrote:
>> >
>> >> Dear People,
>> >>
>> >>   I'm completely new here.
>> >>
>> >>   Attached is a small piece of .c and a .cocci file.
>> >>   There is a "return 41;" in both files, commented out.
>> >>   If I uncomment this "return 41;" in both files then
>> >> spatch will not match the pieces any more.
>> >>
>> >>   Could you please help me to undertand and circumvent this issue ?
>> >
>> > I have not noticed this problem before, but I suspect that it is due to
>> > the fact that Coccinelle is matching the control-flow path and not the
>> > abstract syntax tree. In a control-flow graph, nothing follows a return.
>> >
>> > julia
>>
>> Thank You,
>> I tried to sneak around the problem with a second "rule" which
>>   translates "return 42" to "auxiliary(42)".
>> My intention was to first change the source in such a way
>>   that the "control-flow" graph does not end at the "return",
>> and then hope that the second (accordingly modified) rule would
>>   match.
>> This didn't work, I assume I would have to express the idea of
>>   first applying the first rule
>> then to rebuild the control-flow graph
>>   then try the second rule.
>>   (and finally undo the changes of the first rule in a third rule)
>> I can not force "rebuild" without invoking spatch myself a second time.
>
> If you change all the returns to something else and then match your
> pattern, and then change them it should work.
>
>>
>> ---
>> I'm a bit of a maintainer for the "ngspice" project, which has a vast
>>   amount of very old files, and lots of semi duplicated stuff often crying
>>   for a thourough hair wash,
>> stumbled over this intresting tool, and am tying it for a certain
>>   rewrite I'm currently busy with.
>
> OK,feel free to ask more questions if you run into further issues.
>
> julia

Hello,

  Thank you for your help. I've four or five .cocci files now which
do the job at hand for ngspice quite well. The rewrite of return
to something else with two times invocation of spatch did work.
  Then I found another simpler way. So thats done.

  Playing around, trying to better understand what it means
to have more than one rule, their interaction etc ..
I came to the attached example.
  Here I have basically tried to remove the whole body of a function
iff the function matches two other @rules@
  It seems to work if I use the '*' notation, but doesnt if I use
'+/-'
  Can you give me a hint which helps me to understand this ?

Regards,
  Robert

// (compile "spatch --sp-file ex4.cocci ex4.c")

@r1@
identifier a, foo, Label;
position p1a;
@@
void foo@p1a (int a)
{
  a++;
  if (a)
  goto Label;
  return 1;
  ...
}

@r2@
identifier a, foo, Label;
position p1b;
@@
void foo@p1b (int a)
{
...
 Label:
return 2;
}

@r3@
identifier foo;
position r1.p1a;
position r2.p1b;
@@
void foo@p1a@p1b (...)
{
// this works thy way I'd expect
// * ...
// this doesn't work the way I'd expect
- ...
+ return 42;
}
void foo(int a) {
a++;
if (a)
goto Label;
return 1;
 Label:
return 2;
}


void foo2(int a) {
a++;
 Label:
return 2;
}
___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] [PATCH 2/2] mm: Add kvmalloc_ab_c and kvzalloc_struct

[Matthew Wilcox]

On Wed, Feb 14, 2018 at 11:22:38AM -0800, Kees Cook wrote:
> > +/**
> > + * kvmalloc_ab_c() - Allocate memory.
> 
> Longer description, maybe? "Allocate a *b + c bytes of memory"?

Done!

> > + * @n: Number of elements.
> > + * @size: Size of each element (should be constant).
> > + * @c: Size of header (should be constant).
> 
> If these should be constant, should we mark them as "const"? Or WARN
> if __builtin_constant_p() isn't true?

It's only less efficient if they're not const.  Theoretically they could be
variable ... and I've been bitten by __builtin_constant_p() recently
(gcc bug 83653 which I still don't really understand).

> > + * @gfp: Memory allocation flags.
> > + *
> > + * Use this function to allocate @n * @size + @c bytes of memory.  This
> > + * function is safe to use when @n is controlled from userspace; it will
> > + * return %NULL if the required amount of memory cannot be allocated.
> > + * Use kvfree() to free the allocated memory.
> > + *
> > + * The kvzalloc_hdr_arr() function is easier to use as it has typechecking
> 
> renaming typo? Should this be "kvzalloc_struct()"?

Urgh, yes.  I swear I searched for it ... must've typoed my search string.
Anyway, fixed, because kvzalloc_hdr_arr() wasn't a good name.

> > +#define kvzalloc_ab_c(a, b, c, gfp)kvmalloc_ab_c(a, b, c, gfp | 
> > __GFP_ZERO)
> 
> Nit: "(gfp) | __GFP_ZERO" just in case of insane usage.

Fixed!

> It might be nice to include another patch that replaces some of the
> existing/common uses of a*b+c with the new function...

Sure!  I have a few examples in my tree, I just didn't want to complicate
things by sending a patch that crossed dozens of maintainer trees.

___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci