[Cocci] Deleting unused declarations for variables with SmPL?

[SF Markus Elfring]

Hello,

I have tried another simple script out for the semantic patch language.

@deletion@
identifier x;
type t;
@@
-t x;
 ... when != x


elfring@Sonne:~/Projekte/Linux/next-patched> spatch 
~/Projekte/Coccinelle/Probe/delete_unused_variable1.cocci init/main.c
…
@@ -101,22 +101,6 @@
 
 #define CREATE_TRACE_POINTS
 #include 
-
-static int kernel_init(void *);
-
-extern void init_IRQ(void);
…


Now I wonder about the generated change suggestions.
Does such a transformation approach need any extensions for the safe handling
of function declarations?

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

[Cocci] More applications for “CTL-VW”?

[SF Markus Elfring]

Hello,

Some software evolution happened since the technology “computation tree logic
with variables and witnesses” was published by the document “A Foundation for
Flow-Based Program Matching Using Temporal Logic and Model Checking”.
http://coccinelle.lip6.fr/papers/popl09.pdf
https://doi.org/10.1145/1480881.1480897

Are you still looking for possibilities to increase its usage in more areas?

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

Re: [Cocci] uses of Coccinelle

[SF Markus Elfring]

> It would be helpful to me to have a list of some things that Coccinelle
> has recently been used for.

Are you looking for use cases and corresponding software applications
which have not been discussed on this mailing list before?

Did you try any internet searches out for development topics like
b

Re: [Cocci] Checking patches for questionable comma expressions in if conditions

[SF Markus Elfring]

> The below spatch works for me - and finds the cases I was looking
> for in report mode.

This is nice.


> In patch mode it fixes some in a bad way though due to some additional "bugs"
> in the if statement like:
…
> -   if ((notify->event = event), event->refs) {
> +   (notify->event = event);
> +   if (event->refs) {

I am curious on how software development considerations will evolve further
for such generated patches.

Will the shown script for the semantic patch language need any more fine-tuning?

Would the following transformation variant result in desirable differences
(after the specification of extra parentheses)?


@badif@
position P;
statement S;
expression E1,E2;
@@
 if@P ((E1),E2) S

…

@fixbadif depends on patch && badif@
position badif.P;
statement S;
expression badif.E1,badif.E2;
@@
+E1;
 if@P (
-  (E1),
   E2)
  S


> -   if (mask = 0, data = 0, ram->diff.rammap_11_0a_03fe) {
> +   mask = 0, data = 0;
> +   if (ram->diff.rammap_11_0a_03fe) {
>
> In futher cases it is not clear if the unconditional part really was
> intended to take effect outside the conditional code so it is not
> clear if the placement before the if () is technically correct

How do you think about to convert such a development concern into a more
advanced source code search pattern?

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

Re: [Cocci] Weird problem trying to match code inside a function

[SF Markus Elfring]

> Can you shed some light?

Did you notice the following information in the manual for the semantic
patch language?
https://github.com/coccinelle/coccinelle/blob/dd206b29bf372a8f8e63ffe549f8184e10f2ea7e/docs/manual/cocci_syntax.tex#L1607

“…
All matching done by a SmPL rule is done intraprocedurally.
…”


Can this trigger software development considerations when you try
to add source code after a found function implementation?

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

Re: [Cocci] Adjustment for const qualification

[SF Markus Elfring]

>> How do you think about to try the following SmPL script variant out?
>>
>> @replacement@
>> @@
>> -const
>> +__genl_const
>>  struct
>> (
>>  genl_multicast_group
>> |genl_ops
>> )
> 
> This is rejected by the semantic patch parser.

Can my update suggestion make sense if the parsing software
will be adjusted anyhow?

Does this variant need a small adjustment to get it working
with the current tool version?

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

Re: [Cocci] Adjustment for const qualification

[SF Markus Elfring]

> https://git.kernel.org/pub/scm/linux/kernel/git/backports/backports.git/tree/patches/0027-genl-const/genl-const.cocci

How do you think about to try the following SmPL script variant out?

@replacement@
@@
-const
+__genl_const
 struct
(
 genl_multicast_group
|genl_ops
)


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

Re: [Cocci] Compacting parameters into fewer lines

[SF Markus Elfring]

>> @rule1@
>> expression x;
>> expression list y;
>> @@
>> -DBG_PRINTF
>> +NV_PRINTF
>>    (
>> -  (x),
>>     y);
> 
> This doesn't work:

Do you care if a macro (or function) parameter is optionally enclosed by 
parentheses?


> -    DBG_PRINTF((DBG_MODULE_OS, DEBUGLEVEL_ERRORS,
> -    "NVRM: x86emu: int $%d (eax = %08x)\n", num, M.x86.R_EAX));
> +    NV_PRINTF();

Does this test result need any further clarification for the desired
software behaviour on an other change granularity?


> I always appreciate optimization suggestions.

I have got another software development idea for this transformation approach.

How do you think about to improve the replacement specification a bit more
by combining the variants A  till D into a single SmPL rule which will use
a nested SmPL disjunction?

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

Re: [Cocci] Compacting parameters into fewer lines

[SF Markus Elfring]

> Attached.

I have taken this transformation approach as an opportunity to take another look
at implementation details for further software development considerations.


@rule1@
expression x;
expression list y;
@@
-DBG_PRINTF
+NV_PRINTF
  (
-  (x),
   y);


You repeated additions of identifiers in a few SmPL rules. I would find it nicer
to combine corresponding deletions into SmPL disjunctions (when you would like
to avoid to fiddle with regular expressions as SmPL constraints).


@A depends on rule1@
@@
 NV_PRINTF(...,
-  \(DBG_LEVEL_INFO \| DEBUGLEVEL_TRACEINFO \| DBG_LEVEL_SETUPINFO \| 
DEBUGLEVEL_SETUPINFO\)
+  LEVEL_INFO
   , ...);

@B depends on rule1@
@@
 NV_PRINTF(...,
-  \(DBG_LEVEL_USERERRORS \| DEBUGLEVEL_USERERRORS\)
+  LEVEL_NOTICE
   , ...);

@C depends on rule1@
@@
 NV_PRINTF(...,
-  \(DBG_LEVEL_WARNINGS \| DEBUGLEVEL_WARNINGS\)
+  LEVEL_WARNING
   , ...);

@D depends on rule1@
@@
 NV_PRINTF(...,
-  \(DBG_LEVEL_ERRORS \| DEBUGLEVEL_ERRORS\)
+  LEVEL_ERROR
   , ...);


Do you find such SmPL code adjustments useful?

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

Re: [Cocci] Search/replace inside string constants?

[SF Markus Elfring]

> @script:python s@
> c << r.c;
> c2;
> @@
> if c.startswith('"NVRM: '):
> coccinelle.c2 = '"' + c[7:];
> else:
> coccinelle.c2 = c;

I have got another software development idea for this transformation approach.
The detection of unwanted prefixes could be moved into a regular expression
like “^"NVRM: ” for the constraint of the metavariable for which SmPL 
inheritance
is used here, couldn't it?
The shown SmPL rule “s” needs to work only with matching data then so that
the Python code could be reduced to the statement “coccinelle.c2 = '"' + c[7:]”.

How do you think about to try such a script variant out besides adjustments
for comma positions?
https://systeme.lip6.fr/pipermail/cocci/2018-July/005212.html

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

Re: [Cocci] Search/replace inside string constants?

[SF Markus Elfring]

> @script:python s@
> c << r.c;
> c2;
> @@
> if c.startswith('"NVRM: '):
> coccinelle.c2 = '"' + c[7:];
> else:
>coccinelle.c2 = c;

I suggest to reconsider the action if no modification should be performed 
finally.
How do you think about to use the statement “cocci.include_match(False)”
in the else branch instead?


> But this didn't:

I wonder also about the shown source code situation that an unwanted prefix
could be still preserved in the error message from such a transformation 
example.

Would you like to show your final SmPL replacement rule here?

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

[Cocci] Applicability of SmPL inheritance?

[SF Markus Elfring]

Hello,

I would like to clarify another combination of functionality from the semantic
patch language.
The following small SmPL script can be constructed to find some function calls.

@rtg@
identifier F, G;
@@
 F(..., 9);
*G(1, ...);

@rth@
identifier F, H;
@@
 F(..., 9);
*H(2, ...);


The important detail is here that both SmPL rules specify to search for
the same function calls before other source code should be found.
This common SmPL code could be moved into another SmPL rule.

@rpx@
identifier F;
position P;
@@
 F(..., 9);@P

@rpg@
identifier rpx.F, G;
position rpx.P;
@@
 F(..., 9);@P
*G(1, ...);

@rph@
identifier rpx.F, H;
position rpx.P;
@@
 F(..., 9);@P
*H(2, ...);


I became curious to know if the shown inherited information could be used also
without repeating SmPL code for a precondition.
Can the search be continued directly behind the determined source code position?

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

Re: [Cocci] Increasing usage of array allocation functions with SmPL

[SF Markus Elfring]

> I've been doing some large treewide changes to the allocators,

I find your update suggestion “mm: Use overflow helpers in kmalloc_array*()” 
interesting.

https://lkml.org/lkml/2018/5/31/877
https://patchwork.kernel.org/patch/10442283/
https://lkml.kernel.org/r/<20180601004233.37822-7-keesc...@chromium.org>


It seems that corresponding work became noteworthy news “4.18 Merge window, 
part 2”.
https://lwn.net/Articles/757187/


Now I am curious on how software evolution will be continued according to such
a transformation pattern.
https://patchwork.kernel.org/project/LKML/list/?state=*=alloc_array


> and I notice that Coccinelle does something odd for a specific case.

Will there happen any more evolution in this software area?

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

[Cocci] Searching for constants between shift operators with SmPL

[SF Markus Elfring]

Hello,

The following script for the semantic patch language can mark a bit of source
code also in a corresponding example.


@display@
constant C;
expression A, B;
identifier X;
type T;
@@
 T X = A
 <<
*C
 <<
 B;


int main(void)
{
unsigned int a = 2, b = 4;
unsigned long c = a << 2 << b;
}


1. I get the error message “minus: parse error” after the addition of
   a SmPL ellipsis behind the metavariable “B”.

2. I have observed that no source code is found if I omit the metavariables “T”
   and “X” (omission of the assignment target) in a SmPL script variant.


How do you think about to clarify these software situations any more?

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

[Cocci] Addition of a data type property with SmPL

[SF Markus Elfring]

Hello,

I would like to try another source code transformation out with the help of
the semantic patch language.

@addition@
identifier var;
type T;
@@
 T
+const
 * var;


elfring@Sonne:~/Projekte/Coccinelle/janitor> spatch --parse-cocci 
add_const3.cocci
init_defs_builtins: /usr/local/bin/../lib/coccinelle/standard.h
plus: parse error: 
  File "add_const3.cocci", line 6, column 1, charpos = 42
  around = 'const',
  whole content = +const


* How do you think about this test result?

* Can the addition of such a data type property be generally avoided
  if it would be present already?

https://github.com/coccinelle/coccinelle/issues/49

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

[Cocci] High level restriction of function calls with SmPL

[SF Markus Elfring]

Hello,

I would like to try another source code transformation out with the help of
the semantic patch language.
The following approach can express a bit of information I became interested in.

 {
 ... when any
 when != action(..., input, ...)
 }


Now I am looking for ways to restrict (or filter) such function calls further.
The passed parameter should correspond to a specific data type property.
Can it be determined here together with a scripted constraint?

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

[Cocci] Support for C++ delete expressions?

[SF Markus Elfring]

Hello,

The information “make a small attempt to parse C++ files” is provided for
the parameter “--c++” of the program “spatch”.
How does the software development situation look like for the handling
of “delete expressions”?
http://en.cppreference.com/w/cpp/language/delete

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

Re: [Cocci] Evolution around profiling of SmPL script execution

[SF Markus Elfring]

>How should the execution of each SmPL rule be identified there?

Can the following source code adjustment help a bit besides the general 
possibility
to clarify additional data export formats?

diff --git a/cocci.ml b/cocci.ml
index 64503ee9..43cfc996 100644
--- a/cocci.ml
+++ b/cocci.ml
@@ -1563,7 +1563,7 @@ let printtime str = Printf.printf "%s: %f\n" str 
(Unix.gettimeofday ())
 
 let rec apply_cocci_rule r rules_that_have_ever_matched parse_strings es
 (ccs:file_info list ref) =
-  Common.profile_code r.rule_info.rulename (fun () ->
+  Common.profile_code ("Rule " ^ r.rule_info.rulename) (fun () ->
 show_or_not_rule_name r.ast_rule r.rule_info.ruleid;
 show_or_not_ctl_text r.ctl r.metavars r.ast_rule r.rule_info.ruleid;
 

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

Re: [Cocci] Evolution around profiling of SmPL script execution

[SF Markus Elfring]

> I find the corresponding description improvable for the provided data.

How can it be achieved that the execution of SmPL rules will be measured also
for supported scripting languages?

Will it be appropriate to execute these places by the function 
“Common.profile_code”?

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

[Cocci] Increase precision for display of SmPL script execution durations

[SF Markus Elfring]

Hello,

The Coccinelle software can display profiling results for the execution
of SmPL scripts. The measured durations are formatted in a way so that
the information “0.000 sec” is presented for some functions so far.
I guess that these data processing efforts were performed with a non-zero
time value.
How do you think about to show this detail precisely?

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

[Cocci] Evolution around profiling of SmPL script execution

[SF Markus Elfring]

Hello,

The Coccinelle software supports profiling for the execution of SmPL scripts
to some degree.
I find the corresponding description improvable for the provided data.

1. I would find an other separation for the available columns nicer.

2. I suggest to add a column “area” so that the measured data processing
   can be distinguished better.
   How should the execution of each SmPL rule be identified there?

3. The output of measurement units could be occasionally omitted.


Will the display become more configurable for these software profiling results?

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

[Cocci] Using data from a parameter list with SmPL

[SF Markus Elfring]

Hello,

A specific function can be found also by a selection on its parameter list.
The semantic patch language provides a metavariable type for this purpose.

I would occasionally like to create another function variant then.
It should get a shorter parameter list with a few elements from the other list.
Is it possible to construct something based on the first and second list element
in a generic way?

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

Re: [Cocci] Moving a function body to an other source code place with SmPL

[SF Markus Elfring]

>> I have noticed a moment ago that a blank line is not marked by the SmPL
>> asterisk operator (for a small source code example) so far.
>>
>> Can such whitespace characters be also preserved there anyhow?
> 
> No.  Whitespace is never preserved in metavariables.

I guess that this aspect will trigger further software development consequences.

How should a function body be converted into a part of a macro then?


>> How will the software behaviour evolve if I stumble on the message
>> “Fatal error: exception Coccinelle_modules.Common.Timeout” after passing
>> the parameter “--timeout 123” for a change attempt with a C++ source file?
>> (Am I too impatient here?)
> 
> No evolution is planned.  I see no reason why matching the body of a
> function should intrinsically cause a timeout.

I am also unsure if the Coccinelle software can cope in an other time frame
with another example file I am experimenting a bit.

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

Re: [Cocci] Moving a function body to an other source code place with SmPL

[SF Markus Elfring]

>> It would be occasionally nice if an implementation of a function could be
>> completely stored into a metavariable.
>> Is a statement list variable appropriate for this use case?
> 
> Yes.

Thanks for your acknowledgement that it should usually work.


I have noticed a moment ago that a blank line is not marked by the SmPL
asterisk operator (for a small source code example) so far.

Can such whitespace characters be also preserved there anyhow?


>> Can these data be moved to an other function (or macro definition)?
> 
> Yes.  A statement list variable can be added anywhere a list of statements
> is allowed, ie not necessarily as the complete body of a block.

How will the software behaviour evolve if I stumble on the message
“Fatal error: exception Coccinelle_modules.Common.Timeout” after passing
the parameter “--timeout 123” for a change attempt with a C++ source file?
(Am I too impatient here?)

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

[Cocci] Moving a function body to an other source code place with SmPL

[SF Markus Elfring]

Hello,

I am curious on how good the Coccinelle software can support a specific
source code transformation:
It would be occasionally nice if an implementation of a function could be
completely stored into a metavariable.
Is a statement list variable appropriate for this use case?

Can these data be moved to an other function (or macro definition)?

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

Re: [Cocci] Coccinelle 1.0.6: OpenMP #pragma directive leads to function ignore

[SF Markus Elfring]

> We can try to make the parsing of #pragmas more flexible.

I am also curious on further software evolution in this area for a while.
https://github.com/coccinelle/coccinelle/issues/51

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

Re: [Cocci] Checking software development progress

[SF Markus Elfring]

Hello,

I have noticed a moment ago that a few additional commits were published.
It might be nice to test this development a bit more.

I submitted the command “make distclean” and built the software by the
command “./autogen && ./configure && make world” as usual.
But I wonder about the message “Nothing to be done for 'docs'”.

Regards,
Markus
___
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

[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] [v2] Coccinelle: zalloc-simple: Delete function “kmem_cache_alloc” from SmPL rules

[SF Markus Elfring]

> I removed the blank line at EOF,
> then applied to linux-kbuild/misc.

I have taken another look at this script for the semantic patch language.
I imagined that I could refactor the shown SmPL disjunctions a bit.
But I noticed then that these SmPL rules contain a development mistake.

The deletion for a call of the function “memset” depends on the specification
that a size determination is passed by the expression “E1”.
The function “kmem_cache_alloc” was specified despite of the technical detail
that this function does not get a parameter passed which would correspond
to such a size information.
https://elixir.free-electrons.com/linux/v4.15/source/tools/testing/radix-tree/linux/slab.h#L14
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/tools/testing/radix-tree/linux/slab.h?id=537659c08a7da298aa748854f65f2aa1f31b1378#n14

Thus I suggest to remove it from the first two SmPL rules and omit the rule 
“r4”.
Will the rule set be more consistent then?

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

Re: [Cocci] Coccinelle: alloc_cast: Add more memory allocating functions to the list

[SF Markus Elfring]

> +// Copyright: (C) 2017 Himanshu Jha GPLv2.

* Is the addition “(C)” required?
* Does the year number need an update?



My software development attention was caught by further implementation details
in this evolving SmPL script.


> +@depends on context && r1@

Will the use of a position variable be helpful here?



> +  \(kmalloc\|kzalloc\|kcalloc\|kmem_cache_alloc\|kmem_cache_zalloc\|

Did you consider to handle the relevant function names by a metavariable
instead of a SmPL disjunction?

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

Re: [Cocci] Coccinelle: alloc_cast: Add more memory allocating functions to the list

[SF Markus Elfring]

> Well, you didn't keep the semantic patch in the message.

You can take another look in other information systems (if desired).
https://systeme.lip6.fr/pipermail/cocci/2018-January/004848.html


>> How do you think about to avoid the extra initialisation
>> when only the operation mode “context” or “patch” would be active?
> 
> context and patch use the regular expression too.

Where?


> All forms of the rule need it, to keep the casts that contain sparse 
> annotations.

How do “annotations” matter here?


Is a specific variable used only by two SmPL rules?

…
> +m = re.compile(pattern)
…
> @script:python depends on report@
…
> +if m.search(t) != None:
…


Why are two underscores used as a search pattern in this use case?

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

Re: [Cocci] [PATCH] Coccinelle: alloc_cast: Add more memory allocating functions to the list

[SF Markus Elfring]

My software development attention was caught by another implementation detail
in this evolving SmPL script.


> +@initialize:python@

The added script rule should get a condition.
Would the specification “depends on report” be appropriate there?


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

Re: [Cocci] Coccinelle: alloc_cast: Add more memory allocating functions to the list

[SF Markus Elfring]

> Add more memory allocating functions that are frequently used in the kernel
> code to the existing list and remove the useless casts where it is
> unnecessary.

Thanks for your approach to extend this SmPL script.

I would find the term “selection” more appropriate than the word “list” here.



>+  \(kmalloc\|kzalloc\|kcalloc\|kmem_cache_alloc\|kmem_cache_zalloc\|

I suggest to choose an other code layout for such growing SmPL disjunctions.
How are the chances to specify each function name on a separate script line?


Would you ever like to reduce code duplication by including external files?


Could an alternation (regular expression) be used for a SmPL constraint?

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

Re: [Cocci] Coccinelle: kzalloc-simple: Rename kzalloc-simple to zalloc-simple

[SF Markus Elfring]

> Rename kzalloc-simple to zalloc-simple since now the rule is not
> specific to kzalloc function only, but also to many other zero memory
> allocating functions specified in the rule.

1. Please add the tag “Suggested-by” to the commit description.

   See also:
   Rename the SmPL script “kzalloc-….cocci”?
   https://systeme.lip6.fr/pipermail/cocci/2018-January/004803.html
   https://lkml.kernel.org/r/

2. Please try this update suggestion once more by using the command “git mv”.

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

Re: [Cocci] Automatic generation of SmPL rules by a script rule

[SF Markus Elfring]

> Well, I was thinking that you could eg make a script like:
> 
> @script:ocaml@
> e << r.e;
> @@
> 
> Printf.printf "@@\n";
> Printf.printf "expression f;\n";
> Printf.printf "@@\n\n";
> Printf.printf "-f(%s);\n" e

I would prefer to use the available programming languages directly
instead of starting the spatch program for such file generation.


> But I'm not sure that the parser of script code would be happy with a @ in
> the script code, so you would have to do some trick to get around that.

Would you like to continue the clarification for the topic “Configuration
or escaping of @ characters for embedded programming language scripts”?
https://github.com/coccinelle/coccinelle/issues/36


> I'm not interested in spending time on it in the foreseeable future.

But I imagine that I would like to show related update suggestions
around SmPL scripts because of other approaches then.
Will alternatives become useful?


> If anyone else wants to, the code is there...

Would you like to point any specific source files out for the current
intermediate development status?

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

Re: [Cocci] Automatic generation of SmPL rules by a script rule

[SF Markus Elfring]

> The simplest thing would be to just print the rule you want in a
> python/ocaml script rule.

I would like to adjust a SmPL execution environment for special use cases 
somehow.
How would “printing” be useful here?


> Some support was added at one point for generating rules based on matches
> from other rules,

Such information sounds promising.


> but that code has not been maintained, and I don't think it is likely
> to be updated in the future.

I am curious if there are still any chances to revive corresponding approaches.


Is it safer therefore to generate advanced SmPL script files by external
software tools (at the moment)?

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

[Cocci] Automatic generation of SmPL rules by a script rule

[SF Markus Elfring]

Hello,

Is it possible to generate additional rules for a specific execution environment
of the semantic patch language by an advanced script rule?

Can a special rule generation be avoided from external software tools?

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

Re: [Cocci] [v3] runchecks: Generalize make C={1, 2} to support multiple checkers

[SF Markus Elfring]

> I do feel confident that the benefits of python for this outweighs the 
> drawbacks
> compared to my initial shell script implementation, or using perl or even C.
>
> Further advice on this appreciated,

I got further ideas around this software situation. I am curious on how they fit
to your vision.

One of the challenges for integration of your contribution can also be the
acceptance of corresponding configuration files. There are design choices
available to work with suggested data structures.

How do you think about the develop an official data format specification
for which the shown Python script could be the first reference implementation?
Alternative implementations could be applied on concrete demand.


I would like to add another development concern:

* Do all (Python) classes need to be stored within the same script file so far?

* Do we need to think about structures around plug-ins (or add-ons) already?

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

Re: [Cocci] [v3] runchecks: Generalize make C={1, 2} to support multiple checkers

[SF Markus Elfring]

> As I commented to you, some of it is a bit more in the class of good 
> enhancements 
> so whatever I haven't changed now that resonated with me,

I find that some information could be better integrated already now.


> I'll pick up later if the general idea is accepted.

I am curious on how the waiting queue for remaining improvement possibilities
will be managed for this evolving software tool.


> Sorry if this was confusing.

I would appreciate a corresponding issue ordering somehow.


> Thanks for all the careful comments and suggestions!

Now I would like to add another development concern.

I find source code places like the following suspicious in the script 
“scripts/runchecks”
because the passed variable contents might need extra care.

…
+def RegexFilter(self, line, verbose):
…
+r = "^(.*:\d+:)\s(\w+:)\s(%s.*)$" % regex[0]
…
+def Postprocess(self):
…
+self.cmdvec.append("-Wno-%s" % self.sparse_name(e))
…

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

Re: [Cocci] [v3] runchecks: Generalize make C={1, 2} to support multiple checkers

[SF Markus Elfring]

> +Supported syntax of …

Did you change the mind since your response “Good idea, will do” on 2017-12-23?
https://github.com/torvalds/linux/commit/7bd67f980fdf33031c54955f7e04b435c267886e#r26449420


> +The ``line_len`` directive defines the upper bound of characters per line
> +tolerated in this directory. Currently only ``checkpatch`` supports this
> +command. …

Should such a description be adjusted after you became aware of additional
documentation details?

Can it be that any of (my) previous questions and review comments are still
“unanswered” with this third documentation approach?

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

Re: [Cocci] [v3 0/1] Support for generalized use of make C={1, 2} via a wrapper program

[SF Markus Elfring]

Dear Knut,

You chose to offer a cover letter for software adjustments which are contained
in a single update step.
How do you think about to integrate this information in the change log area
of the other message (patch)?


> Version 2 and 1 of this set and related discussion can be found here:

Did any other information sources become also useful for the improvement
of the initial proposal?

Examples:
* cocci@systeme.lip6.fr
* 
https://github.com/torvalds/linux/compare/master...knuto:runchecks#commit_comments_bucket

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

Re: [Cocci] Coccinelle: kzalloc-simple: Add more zero allocating functions

[SF Markus Elfring]

>>> The cast is useful when it is to a non-pointer type.
>>
>> Will it be needed then to use an other metavariable for the assignment 
>> target?
>>
>> How much would you like to distinguish if an item should handle a pointer
>> (or not)?
> 
> The compiler will complain about an assignment between an integer and a 
> pointer,

This tool distinguishes data types better.


> so one can assume that if the code is
> 
> x = (T *)kmalloc();
> 
> then x has pointer type.

We “hope” so.

How do you think about restrict the type for an acceptable target expression?


> If it doesn't have type T *, it doesn't matter.

I have got an other opinion for the corresponding specification in SmPL scripts.
I would prefer to avoid another bit of logical confusion.

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

Re: [Cocci] Coccinelle: kzalloc-simple: Add more zero allocating functions

[SF Markus Elfring]

> - x = (T)kmalloc(E1,E2);
> + x = (T)kzalloc(E1,E2);
>
> This for useless pointer cast which is done implicitily.

 Actually, the above rule is for the case where the cast is useful.
>>
>> * Have you got any special aspects in mind here?
>>
>> * How do you think about to restrict it for pointer data types?
> 
> The cast is useful when it is to a non-pointer type.

Will it be needed then to use an other metavariable for the assignment target?

How much would you like to distinguish if an item should handle a pointer
(or not)?

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

Re: [Cocci] Coccinelle: kzalloc-simple: Add more zero allocating functions

[SF Markus Elfring]

>>> - x = (T)kmalloc(E1,E2);
>>> + x = (T)kzalloc(E1,E2);
>>>
>>> This for useless pointer cast which is done implicitily.
>>
>> Actually, the above rule is for the case where the cast is useful.

* Have you got any special aspects in mind here?

* How do you think about to restrict it for pointer data types?


>> The (T *) rule should be above this one, because that is for the case
>> where the cast is not needed.  I don't remember if this is done correctly.
>> Please check.
> 
> Oops! Yes, I somehow hurriedly made the typo.

Does such a kind of feedback mean that the specification of pointer casts
will be adjusted once more for this evolving SmPL script?

Would you like to express the handling of optional items in a specific way?

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

Re: [Cocci] [PATCH] Coccinelle: kzalloc-simple: Add more zero allocating functions

[SF Markus Elfring]

> We already have zero memory allocator functions to set the memory to
> 0 value instead of manually setting it using memset.

Thanks for your extension of this script for the semantic patch language.

Will this update suggestion get any better chances than the approach
“Script to replace allocate and memset with zalloc functions”?
https://systeme.lip6.fr/pipermail/cocci/2016-August/003510.html


> +/// Use zeroing allocator rather than allocator followed by memset with 0

Do you find the shown function name list complete now?

Did you omit a name like “kvm_kvzalloc” intentionally?


How do you think about the possibility to analyse relevant source files for
functions with the mentioned property?


> +(
> +- x = kmalloc(E1,E2);
> ++ x = kzalloc(E1,E2);
> +|

You suggest to use another application for the SmPL disjunction.
How do you think about to refactor this specification a bit like the following?

+(
+ x = 
+-kmalloc
++kzalloc
+(E1, E2);
+|



> +|
> +- x = (T *)kmalloc(E1,E2);
> + x = kzalloc(E1,E2);
> +|

Why do you find it appropriate to omit a cast at this place while it is
preserved at other places?

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

Re: [Cocci] Transformation challenges with SmPL around “LIST_FOR_EACH_ENTRY”

[SF Markus Elfring]

>> @adjustment@
>> expression ex;
>> statement S;
>> @@
>> -LIST_FOR_EACH_ENTRY
>> +hlist_for_each_entry
>>  (..., ...,
>> -ex,
>>  ...)
>>  S
> 
> This is not completely a good idea.

I tried to show another approach.


> The ... in the argument list will match a sequence of things, not a single 
> thing.

How does this information fit to the specification of the SmPL ellipsis
as a placeholder for the last macro parameter?


> It could be:
> 
> -LIST_FOR_EACH_ENTRY
> +hlist_for_each_entry
>  (e1,e2,

Are these metavariables required for such an use case?


> -ex,
>  ...)
>  S

Can such a transformation variant have nicer run time characteristics
in comparison to the initial SmPL script example?

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

Re: [Cocci] Transformation challenges with SmPL around “LIST_FOR_EACH_ENTRY”

[SF Markus Elfring]

>> I think I've found a bug in spatch,

You showed another opportunity for further development considerations.


>> or maybe I'm just using it wrong.

Not really.

But the specification in the shown small SmPL script could be adjusted.


>> - LIST_FOR_EACH_ENTRY(c,f,g,member) S
>> + hlist_for_each_entry(c,f,member) S

> Actually, the problem is that you have removed S and dded it back.
> Then you are relying on Coccinelle to do the pretty printing,
> and all comments will be dropped.  Just rewrite your rule as follows,
> and everything will be fine:

> - LIST_FOR_EACH_ENTRY(c,f,g,member)
> + hlist_for_each_entry(c,f,member)
>   S

How do you think about further possibilities?

Can it be also sufficient to express only the source code adjustment for
two details?

* Replacement of a macro name

* Deletion (or omission) of a parameter


@adjustment@
expression ex;
statement S;
@@
-LIST_FOR_EACH_ENTRY
+hlist_for_each_entry
 (..., ...,
-ex,
 ...)
 S

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

Re: [Cocci] [v4] Coccinelle: fix parallel build with CHECK=scripts/coccicheck

[SF Markus Elfring]

> Setting NPROC=1 is a reasonable solution;

It can be sufficient for the usual purposes of the shell script 
“scripts/coccicheck”.


> spatch does not create the subdirectory.

I would like to point out that further development efforts will be needed
if such a special directory handling should be avoided generally.
How much do care about consequences if parameters for additional parallelisation
would be passed over the command line option (or the environment variable)
“SPFLAGS” as it is described in the file 
“Documentation/dev-tools/coccinelle.rst”?

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

Re: [Cocci] Coccinelle: fix parallel build with CHECK=scripts/coccicheck

[SF Markus Elfring]

>>> I didn't want to use a name with the pid, so that one could easily find
>>> this information while Coccinelle is running.
>>
>> Do you mark these data as “hidden” in the file system?
> 
> I don't know what this means.

Do you fiddle with file attributes or use a dot as the first character
in the file name?


>> I imagine that the storage algorithm could become better configurable
>> besides the parameters “--temp-files” and “--tmp-dir”.
> 
> The problem is that running multiple coccinelles each with parallelism is
> fairly pointless,

The situation might be different if the execution environment provides
enough computation resources for processing with special data distributions.


> especially on the same semantic patch.

There can be restrictions usually.


> So the only people who do it will be those who don't understand
> how Coccinelle works.

This might be. - Or do they compare different software versions (in parallel)?


> Those people won't realize that they should use such extra options either.

Some time is needed to become more aware about advanced parameters.

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

[Cocci] Setting the section for a function with SmPL

[SF Markus Elfring]

Hello,

Implementations of various functions will be changed on demand. It can happen
then that you would like to know if the applied changes will result also in
differences for the generated code.

Development tools like “size” can display some information for such a 
comparison.
The total size display might be occasionally not so useful. I imagine that it
can help to split a default section configuration into smaller parts.
https://gcc.gnu.org/onlinedocs/gcc-7.2.0/gcc/Common-Function-Attributes.html#index-section-function-attribute

I would like to append a corresponding attribute to a function signature by the
means of the semantic patch language.

@section_specification@
type T;
@@
T rcar_pcie_enable_msi(...)
+ __attribute__((section ("my_update")))
 {
 ...
 }


Unfortunately, the software “Coccinelle 1.0.6-00345-g2ca0befa” does not like
such an approach so far.

elfring@Sonne:~/Projekte/Linux/next-patched> spatch 
~/Projekte/Coccinelle/janitor/set_section1.cocci drivers/pci/host/pcie-rcar.c
…
plus: parse error: 
  File "/home/elfring/Projekte/Coccinelle/janitor/set_section1.cocci", line 6, 
column 1, charpos = 105
  around = '{',
  whole content =  {


Can the software situation be improved anyhow for this use case?

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

Re: [Cocci] make install broken

[SF Markus Elfring]

>> Which information are you missing from my software surprises?
> You just showed the error that looks similar to mine.

I have tried another rebuild of the current software out.


> You miss the part about how you configured and installed it.

Would you like to take another look at affected implementation details?


> And what exact commit you've used.

elfring@Sonne:~/Projekte/Coccinelle/20160205> make distclean && git checkout 
master && git pull && ./autogen && ./configure && echo "$(./version.sh)" && 
grep VERSION=1 Makefile.config
…
1.0.6-00335-g6e5973d4
VERSION=1.0.6-00335-g6e5973d4
elfring@Sonne:~/Projekte/Coccinelle/20160205> make world
…


Sonne:~ # cd /home/elfring/Projekte/Coccinelle/20160205 && make install
…
/usr/bin/install -c -m 755 spatch.opt /usr/local/bin/spatch
/usr/bin/install -c -m 644 standard.h /usr/local/lib64/coccinelle
/usr/bin/install -c -m 644 standard.iso /usr/local/lib64/coccinelle
…
/usr/bin/install -c -m 644 python/coccilib/*.py \
/usr/local/lib64/coccinelle/python/coccilib
…


elfring@Sonne:~> /usr/local/bin/spatch --version
spatch version 1.0.6-00335-g6e5973d4 compiled with OCaml version 4.05.0
…


elfring@Sonne:~/Projekte/Linux/next-patched> /usr/local/bin/spatch 
~/Projekte/Coccinelle/janitor/use_seq_putc_or_seq_puts-20161027-a.cocci 
drivers/staging/irda/net/irlmp.c
warning: Can't find macro file: /usr/local/bin/../lib/coccinelle/standard.h
warning: Can't find default iso file: 
/usr/local/bin/../lib/coccinelle/standard.iso
Python error: No module named coccilib.elems


* How should the directory “lib64” be determined for this use case?

* Do I need to add any symbolic links temporarily?

* Will it help to add an installation test to the software build system?


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

Re: [Cocci] make install broken

[SF Markus Elfring]

> Do what I did:
> Describe the problem in a way that makes it easy to reproduce.

I find that did this already, didn't I?

Which information are you missing from my software surprises?

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

Re: [Cocci] make install broken

[SF Markus Elfring]

>> I find that did this already, didn't I?
> No , you didn't.

I can try to repeat some more technical details.


>> Which information are you missing from my software surprises?
> You just showed the error that looks similar to mine.

Yes. - I submitted only a kind of “ping” yesterday.


> You miss the part about how you configured and installed it.

The maintainers are completely informed.


> And what exact commit you've used.

I hope that I am using the published GitHub version mostly.


How do you think about to take another look at any of my previous
clarification requests?

* Further improvements for safer building of the Coccinelle software
  https://systeme.lip6.fr/pipermail/cocci/2017-September/004522.html

* Checking evolution for the build system of the Coccinelle software
  https://systeme.lip6.fr/pipermail/cocci/2017-September/004524.html

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

Re: [Cocci] make install broken

[SF Markus Elfring]

>> Is this software development also relevant for the following error messages?
>>
>> elfring@Sonne:~/Projekte/Linux/next-patched> spatch 
>> ~/Projekte/Coccinelle/janitor/….cocci ….c
>> warning: Can't find macro file: /usr/local/bin/../lib/coccinelle/standard.h
>> warning: Can't find default iso file: 
>> /usr/local/bin/../lib/coccinelle/standard.iso
>> Python error: No module named coccilib.elems
> Correct. It fixes that issue.

It is nice that the current tool is working for you now as expected.

I am curious on what I need to change more so that I can report the same
for my test system.
Would you like to contribute further ideas?

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

[Cocci] Checking for consistency of the version data by the software build system

[SF Markus Elfring]

Hello,

The following command was executed on my test system again.

elfring@Sonne:~/Projekte/Coccinelle/20160205> make distclean && git checkout 
master && git pull && ./autogen && ./configure && echo "$(./version.sh)" && 
grep VERSION=1 Makefile.config
…
1.0.6-00335-g6e5973d4
VERSION=1.0.6-00318-g0bf53049


An essential build script contains the macro call “AC_INIT(…, 
m4_esyscmd([./version.sh]), …)”.
https://github.com/coccinelle/coccinelle/blob/436cc65a41ce2c5885cc7f1ee09b6c14fac1981c/configure.ac#L6

So I would expect that the determined version data will be immediately reused
in generated files. But I notice the shown mismatch occasionally.
Do you observe also similar differences in other software build environments?

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

Re: [Cocci] Further improvements for safer building of the Coccinelle software

[SF Markus Elfring]

> What are you wondering about it?

Was the make script changed in the way that the native executable variant
will not be reinstalled with the suffix “opt” any more?

https://github.com/coccinelle/coccinelle/blob/db8e301e8b28f20149d5edccc996cf6843047f7a/Makefile#L260


Do you find the following command relevant for further considerations?

Sonne:/home/elfring/Projekte/Coccinelle/20160205 # make install
…
/usr/bin/install -c -m 755 spatch.opt /usr/local/bin/spatch
…

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

Re: [Cocci] Checking statement order for patch generation with SmPL support

[SF Markus Elfring]

>> I wonder also about the information how an ordinary for loop could influence
>> the shown source code analysis result for the function 
>> “snd_seq_queue_find_name”
>> when the questionable marked statements are contained in a single if branch.
>> http://elixir.free-electrons.com/linux/v4.13/source/sound/core/seq/seq_queue.c#L241
>> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/sound/core/seq/seq_queue.c?id=c6be5a0e3cebc145127d46a58350e05d2bcf6323#n252
> 
> I don't understand the question.

I hope that we can achieve a better common understanding also for the mentioned
test examples.


> I already explained the issue here.

You tried it.


> Execution can go from queuefree to the top of the loop, to the first if in
> the loop to the second if in the loop that has the dereference.  That is
> how loops work.

I can agree to this view.

But I find the existence of a loop not so relevant for the source code
search pattern which is discussed.


>> @@ -1199,14 +1199,11 @@ void dpcm_be_disconnect(struct snd_soc_p
>>  stream ? "<-" : "->", dpcm->be->dai_link->name);
>>
>>  /* BEs still alive need new FE */
>> -dpcm_be_reparent(fe, dpcm->be, stream);
>>
>>  #ifdef CONFIG_DEBUG_FS
>> -debugfs_remove(dpcm->debugfs_state);
>>  #endif
>>  list_del(>list_be);
>>  list_del(>list_fe);
>> -kfree(dpcm);
>>  }
>>  }
>>
>>
>> I find the shown matches also questionable for this test result.
>> Would you like to clarify such software situations a bit more
>> for the desired handling of statement sequences?
> 
> The list_for_each_entry_safe operator also makes a loop.

Yes. - But how could the Coccinelle software know more about this identifier
during execution of the small script “show_use_after_free3.cocci” than
that it is a macro call in the implementation of the function 
“dpcm_be_disconnect”
(when extra include parameters were not specified)?
http://elixir.free-electrons.com/linux/v4.13/source/include/linux/list.h#L542
http://elixir.free-electrons.com/linux/v4.13/source/sound/soc/soc-pcm.c#L1184

Do you find the minus characters appropriate at the beginning of these three 
lines?

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

Re: [Cocci] Checking statement order for patch generation with SmPL support

[SF Markus Elfring]

> Thers is a control-flow path from the bottom of a loop back up to the top.

I wonder also about the information how an ordinary for loop could influence
the shown source code analysis result for the function “snd_seq_queue_find_name”
when the questionable marked statements are contained in a single if branch.
http://elixir.free-electrons.com/linux/v4.13/source/sound/core/seq/seq_queue.c#L241
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/sound/core/seq/seq_queue.c?id=c6be5a0e3cebc145127d46a58350e05d2bcf6323#n252


I have tried the following SmPL script variant out on another source file.

@usage@
identifier action!~"^.+free$", member, release=~"^.+free$";
expression context, ex;
@@
*release(context);
 ... when != context = ex
 when any
*action(..., (context)->member, ...)


elfring@Sonne:~/Projekte/Linux/next-patched> spatch.opt 
~/Projekte/Coccinelle/janitor/show_use_after_free3.cocci sound/soc/soc-pcm.c
…
@@ -1199,14 +1199,11 @@ void dpcm_be_disconnect(struct snd_soc_p
stream ? "<-" : "->", dpcm->be->dai_link->name);
 
/* BEs still alive need new FE */
-   dpcm_be_reparent(fe, dpcm->be, stream);
 
 #ifdef CONFIG_DEBUG_FS
-   debugfs_remove(dpcm->debugfs_state);
 #endif
list_del(>list_be);
list_del(>list_fe);
-   kfree(dpcm);
}
 }


I find the shown matches also questionable for this test result.
Would you like to clarify such software situations a bit more
for the desired handling of statement sequences?

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

Re: [Cocci] Checking statement order for patch generation with SmPL support

[SF Markus Elfring]

>> But I have got difficulties to interpret it in an useful way.
> 
> Coccinelle follows control-flow paths.

This information is generally fine.


> Thers is a control-flow path from the bottom of a loop back up to the top.

I can not follow with my intermediate understanding to such a view
at the moment.

Why was the combination of a call for the function “strncmp” before a 
“queuefree”
really displayed as an update candidate?


>>> @usage@
>>> identifier action, member, release=~"^.+free$";
>>> expression context,e;
>>> @@
>>> *release(context);
>>>  ... when != context = e
>>>  when any  // to get all results
>>> *action(..., (context)->member, ...)
>>
>> Should the SmPL construct “<+.. ...+>” work also similar to your suggestion?
> 
> <+... ...+> would also not allow context = e after the last match of the
> pattern inside the nest.

This information sounds promising.

I am looking still for possibilities to clarify the overlap better
in the shown functionality.


> A when on a <+... ...+> applies to the entire matched region.

Can the parameter “when” be combined with this construct anyhow?

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

Re: [Cocci] Checking statement order for patch generation with SmPL support

[SF Markus Elfring]

>> Now I wonder why the software “Coccinelle 1.0.6-00242-g3f038a5d” finds
>> this place relevant when the function call sequence does not fit to the order
>> I tried to express for a known use case.
>> I would appreciate further advice.
> 
> Because there is a loop,

This information is appropriate.

But I have got difficulties to interpret it in an useful way.


> and you did nothing to prevent an update to q because the free and the 
> dereference.

I omitted an additional constraint for a simple test.


> @usage@
> identifier action, member, release=~"^.+free$";
> expression context,e;
> @@
> *release(context);
>  ... when != context = e
>  when any  // to get all results
> *action(..., (context)->member, ...)

Should the SmPL construct “<+.. ...+>” work also similar to your suggestion?

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

[Cocci] Checking statement order for patch generation with SmPL support

[SF Markus Elfring]

Hello,

I have constructed another small script for the semantic patch language.

@usage@
identifier action, member, release=~"^.+free$";
expression context;
@@
*release(context);
 <+...
*action(..., (context)->member, ...)
 ...+>


The following source code place can be found by such a simple approach
for further software development considerations.
https://lkml.org/lkml/2017/9/6/669

elfring@Sonne:~/Projekte/Linux/next-patched> git checkout next-20170905 && 
spatch.opt ~/Projekte/Coccinelle/janitor/show_use_after_free1.cocci 
sound/pci/ymfpci/ymfpci.c
…
@@ -336,8 +336,6 @@ static int snd_card_ymfpci_probe(struct
legacy_ctrl &= ~YMFPCI_LEGACY_FMEN;
pci_write_config_word(pci, PCIR_DSXG_LEGACY, 
legacy_ctrl);
} else if ((err = snd_opl3_hwdep_new(opl3, 0, 1, NULL)) < 0) {
-   snd_card_free(card);
-   dev_err(card->dev, "cannot create opl3 hwdep\n");
return err;
}
}


I have tried the SmPL script out on another source file.

elfring@Sonne:~/Projekte/Linux/next-patched> spatch.opt 
~/Projekte/Coccinelle/janitor/show_use_after_free1.cocci 
sound/core/seq/seq_queue.c
…
@@ -246,9 +246,7 @@ struct snd_seq_queue *snd_seq_queue_find
 
for (i = 0; i < SNDRV_SEQ_MAX_QUEUES; i++) {
if ((q = queueptr(i)) != NULL) {
-   if (strncmp(q->name, name, sizeof(q->name)) == 0)
return q;
-   queuefree(q);
}
}
return NULL;


Now I wonder why the software “Coccinelle 1.0.6-00242-g3f038a5d” finds
this place relevant when the function call sequence does not fit to the order
I tried to express for a known use case.
I would appreciate further advice.

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

Re: [Cocci] [PATCH v4] Coccinelle: add atomic_as_refcounter script

[SF Markus Elfring]

> > Acked-by: Julia Lawall 

> Thank you very much Julia!

I find that this acknowledgement could be presented a bit too early.


> What is the correct path to merge this?

It seems that you prefer to ignore some of my technical arguments (or 
concerns?).

I hope that a safer source code search approach can still be achieved here.

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

Re: [Cocci] [PATCH v4] Coccinelle: add atomic_as_refcounter script

[SF Markus Elfring]

Dear Elena,

I hoped on a more constructive feedback for remaining implementation details
which should be reconsidered once more.
https://systeme.lip6.fr/pipermail/cocci/2017-August/004341.html

* Will any more revisions be needed for your evolving script until special
  development concerns will be taken into account appropriately?

* How do you prefer to clarify unsafe search patterns finally?

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

Re: [Cocci] [PATCH v4] provide rule for finding refcounters

[SF Markus Elfring]

> changes in v4:
> …

Do you find this cover letter still relevant for the clarification
of remaining open issues in a single SmPL script?

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

Re: [Cocci] Addition of support for conjunctions on types

[SF Markus Elfring]

>> I am looking for descriptions about circumstances under which the 
>> metavariable combination
>> will be useful by the mentioned SmPL conjunctions.
> 
> I still don't understand the question.

It seems that I have got a few understanding difficulties with the added 
functionality.


> Another example is
> 
> (
> (
> struct i
> |
> union i
> )
> &
> t
> )
> 
> Now you have one metavariable, t, that stores the whole type,

I find this technical detail unclear.


> whether it is a struct or a union.

But this information sounds promising.

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

Re: [Cocci] Addition of support for conjunctions on types

[SF Markus Elfring]

> I have no idea what information is wanted.

I am looking for descriptions about circumstances under which the metavariable 
combination
will be useful by the mentioned SmPL conjunctions.

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

Re: [Cocci] Addition of support for conjunctions on types

[SF Markus Elfring]

>> I would like to know a bit more for the application of such a metavariable 
>> combination.

I would appreciate another feedback for this aspect.


>> Unfortunately, I get the information “… Fatal error occurred, no output PDF
>> file produced! …” from data processing by the command “make docs”.
> 
> Fixed.  Thanks for the report.

Thanks for your quick software update “latex fix”.

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

Re: [Cocci] Addition of support for conjunctions on types

[SF Markus Elfring]

> @@
> type t;
> identifier i;
> @@
>
> (
> struct i
> &
> t
> )
>
> will now bind both i and t appropriately.


I would like to know a bit more for the application of such a metavariable 
combination.
I hoped also to read something about it in the current manual.
Unfortunately, I get the information “… Fatal error occurred, no output PDF
file produced! …” from data processing by the command “make docs”.

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

Re: [Cocci] Addition of support for variable attributes

[SF Markus Elfring]

> It is now (github) possible to match and transform a single such attribute
> when it comes after the name of a variable in a variable declaration.

This is a nice extension for your software.

How does this information fit to the wording in the manual?
https://github.com/coccinelle/coccinelle/blob/2776ede39f6f4197eaa0fc8344152e5ed07e0ad3/docs/manual/cocci_syntax.tex#L308
“…
It is not possible to match or remove an attribute, only to add one.
…”


> attribute name __ro_after_init;

Do you imagine any further software evolution if you start the specification
of this metavariable type with two words?

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

Re: [Cocci] Matching function prototypes and casts

[SF Markus Elfring]

>> (
>> *setup_timer(>_timer@tl, \((_func)\| \) \(&\| \) _callback, \((_data)\| 
>> \) E);
>> |
>> *E->_timer@tl.function = \((_func)\| \) \(&\| \) _callback;
>> )
> 
> No, it doesn't work, because \( \| \) matches an expression and there is
> no empty expression.

Will the Coccinelle software become able to generate the desired combination
of casts and address-of operators anyhow automatically?

Can the usage of optional items be expressed in a more convenient way here?

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

Re: [Cocci] Matching function prototypes and casts

[SF Markus Elfring]

> I had --no-includes in my .cocci.

Would you like to transform also any header files by the mentioned approach?


> More insane corner cases:

Are you looking for further clarification there?

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

Re: [Cocci] Matching function prototypes and casts

[SF Markus Elfring]

>> You try to search for variations of a function call and an assignment to
>> a data structure member. It seems that they differ then by the usage of a 
>> cast
>> and the operator “&”.
>> How do you think about to express such search criteria in a succinct way with
>> the help of the semantic patch language?
>>
>> I imagine that nested disjunctions or the SmPL operator “?” could be used
>> for your source code transformation approach.
> 
> I don't know what you have in mind,

Would the following design suggestion be usable?


@check_timer_function_usage@
expression _callback, E;
struct timer_list tl;
identifier _timer;
type _func, _data;
@@

(
*setup_timer(>_timer@tl, \((_func)\| \) \(&\| \) _callback, \((_data)\| \) 
E);
|
*E->_timer@tl.function = \((_func)\| \) \(&\| \) _callback;
)


I wonder that “E” should be passed twice to the shown function call.


> but ? only works on top-level terms (statements, loop headers, etc), not 
> nested expressions.

I assume that this functionality can occasionally be used more often.

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

Re: [Cocci] Matching function prototypes and casts

[SF Markus Elfring]

> (
> -setup_timer(&_E->_timer@_e, _callback, _E);
> |
…
> -_E->_timer@_e.function = (_cast_func)&_callback;
> )

You try to search for variations of a function call and an assignment to
a data structure member. It seems that they differ then by the usage of a cast
and the operator “&”.
How do you think about to express such search criteria in a succinct way with
the help of the semantic patch language?

I imagine that nested disjunctions or the SmPL operator “?” could be used
for your source code transformation approach.

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

Re: [Cocci] parsing of C code

[SF Markus Elfring]

> More importantly; does Julia like red jelly beans more than blue jelly beans?

Would you like to discuss favourite sweets more than to clarify
further improvements in parsing technology also for application
together with the Coccinelle software?   ;-)

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

Re: [Cocci] parsing of C code

[SF Markus Elfring]

> Parsing of foo fails due to the attribute __xxx(yyy) that Coccinelle is
> not able to cope with.

* Do you find information relevant from answers to a question like
  “Context-free grammars versus context-sensitive grammars?”?
  
https://stackoverflow.com/questions/8236422/context-free-grammars-versus-context-sensitive-grammars#answer-8250104

* Do the “attributes” which you would like to support trigger a need
  to work with context-dependent grammars?

* Did you ask any other developers (or software designers) for
  possible solutions around the mentioned aspect?

* Will the software situation improve any more also for the
  programming language “OCaml” (besides tools like “Menhir”)?

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

Re: [Cocci] parsing of C code

[SF Markus Elfring]

>> If it's yacc based you can recover where ever you like.  Knowing how to
>> do it is something of a black art.

> Well, ocamlyacc, to be precise.

Can the software “Menhir” help any more for the needed data processing?
http://gallium.inria.fr/%7Efpottier/menhir/

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

Re: [Cocci] parsing of C code

[SF Markus Elfring]

> I have tried to improve the parsing of C code recently.

This information is useful.


> 1.  More aggressive inclusion of header files,

Why do you need to become “aggressive” there when the corresponding
data processing should be just correct?


> combined with caching of header files.

How do you think about to configure this approach with special parameters?


> flush stdout

Can such a function call be omitted here?


> If some functions are missing in the output when using the new version,
> as compared to the output when using the old version, and if these functions
> are things you might want to process in some way, thenlet me know about
> the problem.

I became more curious on the run time characteristics (as you already know)
for the presented software evolution. I stumbled on some execution challenges
during the application of special source code search patterns.
How would they increase because of the desired inclusion of additional
source (or header) files for analysis approaches which would need them?

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

Re: [Cocci] parsing of C code

[SF Markus Elfring]

> At least for the Linux kernel, you can't just run one make and get all the
> files to be compiled.  Some files are indeed very hard to compile.

How do you think about to point any specific source code examples out
which you find a bit too challenging so far?

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

Re: [Cocci] Comparing statement lists with SmPL

[SF Markus Elfring]

> If you like the results from the second case, what more do you want?

I would like to achieve somehow that the number of presented “false positives”
will become so low so that similar (and extended) SmPL scripts can be used for
more automatic source code transformations with higher confidence.

* How are are the chances to integrate corresponding variants into a script
  collection for which you care also?
  
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/scripts/coccinelle/

* How much does the attention for related issues fit to the software development
  capacity which is available so far?

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

Re: [Cocci] Comparing statement lists with SmPL

[SF Markus Elfring]

>> How should the source code search be improved further here?
> 
> If you like the results from the second case, what more do you want?

* There are also several questionable transformation suggestions generated
  besides the usable ones.

* Will answers belong also to the topic “Get the non-optional nest construct
  completely working for SmPL”?
  https://github.com/coccinelle/coccinelle/issues

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

Re: [Cocci] Comparing statement lists with SmPL

[SF Markus Elfring]

> You would need when any on the ...  Otherwise, it will not match anything
> (perhaps declarations). The s1 after is precludes matching any statement.
> Likewise in the next if.

The suggested variant does still not work in the way I would expect it.

@duplicated_code@
identifier work;
statement s1, s2;
type T;
@@
 T work(...)
 {
 ... when any
*if ((...) < 0)
*{
... when any
*   s1
*   s2
*}
 <+...
*if ((...) < 0)
*{
... when any
*   s1
*   s2
*}
 ...+>
 }


I got some promising test results from the following SmPL approach.

@duplicated_code@
identifier work;
statement s1, s2;
type T;
@@
 T work(...)
 {
 ... when any
*if ((...) < 0)
*{
... when any
*   s1
*   s2
*}
 ... when any
*if ((...) < 0)
*{
... when any
*   s1
*   s2
*}
 ... when any
 }


elfring@Sonne:~/Projekte/Linux/next-patched> XX=$(date) && spatch.opt --timeout 
12 --sp-file ~/Projekte/Coccinelle/janitor/show_same_statements3b.cocci --dir 
sound > 
~/Projekte/Bau/Linux/scripts/Coccinelle/tuning1/next/20170803/same_statements3b.diff
 2> 
~/Projekte/Bau/Linux/scripts/Coccinelle/tuning1/next/20170803/same_statements3b-errors.txt;
 YY=$(date) && echo "$XX | $YY"
Mi 23. Aug 17:25:54 CEST 2017 | Mi 23. Aug 17:29:15 CEST 2017


How should the source code search be improved further here?

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

Re: [Cocci] Comparing statement lists with SmPL

[SF Markus Elfring]

> I have tried another variant out for a source code analysis.

Does the following SmPL script variant make sense?

@duplicated_code@
identifier work;
statement s1, s2;
type T;
@@
 T work(...)
 {
 ... when any
*if ((...) < 0)
*{
...
*   s1
*   s2
*}
 <+...
*if ((...) < 0)
*{
...
*   s1
*   s2
*}
 ...+>
 }


Can this approach find interesting places in any source files?

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

Re: [Cocci] Comparing statement lists with SmPL

[SF Markus Elfring]

>>> The pattern matched in two different functions?
>>
>> Please look once more.
>>
>> Yes. - This is one of the reasons why I ask here again.
>>
>> I would like to choose if a code analysis should happen only within a single 
>> function
>> or on interesting parts from the complete source file.
> 
> Feel free to make a tool of your own if you are not satisfied with the one
> offered you.

This is also possible. - But I wonder more about specific test results based
on the currently provided software.

I got matches for places where I would expect that they should not match.


> Coccinelle applies a rule to one function at a time.

This is also fine for a while.


> That is not going to change.

I imagine that the situation could evolve more if additional development 
resources
will appear somehow.


> If you want to match things in different functions, make two rules.

Additional SmPL rules will search for other details.


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

Re: [Cocci] Comparing statement lists with SmPL

[SF Markus Elfring]

>> How do the presented functions “usb6fire_fw_ezusb_upload” and 
>> “usb6fire_fw_fpga_upload”
>> fit to this information?
> 
> The pattern matched in two different functions?

Please look once more.

Yes. - This is one of the reasons why I ask here again.

I would like to choose if a code analysis should happen only within a single 
function
or on interesting parts from the complete source file.

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

Re: [Cocci] Comparing statement lists with SmPL

[SF Markus Elfring]

>> * A test result was shown from two function implementations.
>>   It can be nice to compare several functions.
>>   Is it also possible that the comparison will be only performed within
>>   the same function bodies?
> 
> If you make a single rule then it will only applied within individual 
> functions.

How do the presented functions “usb6fire_fw_ezusb_upload” and 
“usb6fire_fw_fpga_upload”
fit to this information?

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

Re: [Cocci] Comparing statement lists with SmPL

[SF Markus Elfring]

>> How would you like to treat variations in such log messages?
> 
> They look fine as they are.

I have got other development opinions there depending on the preferred design 
goals.

* The mentioned small SmPL script can also help to find special differences.

* These log statements are similar (and not identical) in the code structure.
  I wonder also about other marked code places how they would fit to
  the search pattern.

* A test result was shown from two function implementations.
  It can be nice to compare several functions.
  Is it also possible that the comparison will be only performed within
  the same function bodies?

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

Re: [Cocci] Comparing statement lists with SmPL

[SF Markus Elfring]

>> * Are there further development challenges to consider for the safe 
>> identification
>>   of unique statements by metavariables?
> 
> If you want to ensure that two metavariables match things
> in different places, then put a position variable on each match
> and use apython rule afterwards to discard the occurrences that
> are both in the same position.

I imagine that such an approach can only matter if there will be
several SmPL rules involved.


I have tried another variant out for a source code analysis.

@duplicated_code@
identifier work;
statement s1, s2;
type T;
@@
 T work(...)
 {
 <+...
*if ((...) < 0)
*{
...
*   s1
*   s2
*}
 ...+>
 <+...
*if ((...) < 0)
*{
...
*   s1
*   s2
*}
 ...+>
 }


elfring@Sonne:~/Projekte/Linux/next-patched> XX=$(date) && spatch.opt -timeout 
34 -j 4 --chunksize 1 --sp-file 
~/Projekte/Coccinelle/janitor/show_same_statements3.cocci --dir sound > 
~/Projekte/Bau/Linux/scripts/Coccinelle/tuning1/next/20170803/same_statements3+.diff
 2> 
~/Projekte/Bau/Linux/scripts/Coccinelle/tuning1/next/20170803/same_statements3+-errors.txt;
 YY=$(date) && echo "$XX | $YY"
Di 22. Aug 10:24:47 CEST 2017 | Di 22. Aug 10:26:04 CEST 2017


Now I find that a test result like the following is worth for further
development considerations.

…
--- sound/usb/6fire/firmware.c
+++ /tmp/nothing/usb/6fire/firmware.c
@@ -246,14 +246,8 @@ static int usb6fire_fw_ezusb_upload(
while (usb6fire_fw_ihex_next_record(rec)) { /* write firmware */
ret = usb6fire_fw_ezusb_write(device, 0xa0, rec->address,
rec->data, rec->len);
-   if (ret < 0) {
kfree(rec);
release_firmware(fw);
-   dev_err(>dev,
-   "unable to upload ezusb firmware %s: data 
urb.\n",
-   fwname);
-   return ret;
-   }
}
 
release_firmware(fw);
@@ -319,13 +313,8 @@ static int usb6fire_fw_fpga_upload(
buffer[i] = bitrev8((u8)*c);
 
ret = usb6fire_fw_fpga_write(device, buffer, i);
-   if (ret < 0) {
release_firmware(fw);
kfree(buffer);
-   dev_err(>dev,
-   "unable to upload fpga firmware: fw urb.\n");
-   return ret;
-   }
}
release_firmware(fw);
kfree(buffer);
…


How would you like to treat variations in such log messages?

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

[Cocci] Checking evaluation of a regular expression for a SmPL constraint

[SF Markus Elfring]

Hello,

Today I published the update suggestion “[PATCH 1/3] ecryptfs: Delete 21 error
messages for a failed memory allocation”.
https://patchwork.kernel.org/patch/9910539/
https://lkml.kernel.org/r/<1dcce3db-c162-c6bc-d1a8-bcf427248...@users.sourceforge.net>

I noticed during the preparation of this change that the implementation of
the function “ecryptfs_add_global_auth_tok” was not automatically found as
an update candidate.
A detailed regular expression is involved for a special constraint in
an evolving SmPL script.

I can pass the specified regular expression also to the program “pcre2test”
(version 10.23-2.5) which indicates a successful match for an identifier
like “kmem_cache_zalloc” then.

Now I wonder about this software situation.
Would anybody like to test once more if another mismatch can be observed
around such regex evaluation within the Coccinelle software?

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

Re: [Cocci] Improving size determinations with SmPL

[SF Markus Elfring]

> The suggested script variant seems to work finally.

I have tried it out once more with the following command.

elfring@Sonne:~/Projekte/Linux/next-patched> spatch.opt --timeout 67 -j 4 
--in-place ~/Projekte/Coccinelle/janitor/safer_size_determination2.cocci fs/jfs
…
EXN: Common.TimeoutNote: processing took74.0s: fs/jfs/jfs_txnmgr.c
…
EXN: Common.TimeoutNote: processing took73.5s: fs/jfs/jfs_xtree.c
…
EXN: Common.TimeoutNote: processing took75.2s: fs/jfs/jfs_dtree.c
…

How do you think about to take another look at the shown execution times?
Are the run time characteristics worth for another clarification?

By the way:
I would find another line break nicer in these messages.

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

Re: [Cocci] Comparing statement lists with SmPL

[SF Markus Elfring]

>> * Are there further development challenges to consider for the safe 
>> identification
>>   of unique statements by metavariables?
> 
> If you want to ensure that two metavariables match things in different
> places, then put a position variable on each match and use apython rule
> afterwards to discard the occurrences that are both in the same position.

I hoped for a more convenient search specification to reduce duplicate
source code a bit.

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

Re: [Cocci] Comparing statement lists with SmPL

[SF Markus Elfring]

>> elfring@Sonne:~/Projekte/Linux/next-patched> git checkout next-20170803 && 
>> spatch.opt ~/Projekte/Coccinelle/janitor/show_same_statements3.cocci 
>> fs/ubifs/lpt.c
>> …
>> @@ -1974,10 +1974,6 @@ again:
>>  int ret, lnum = lprops->lnum;
>>
>>  ret = scan_cb(c, lprops, path[h].in_tree, data);
>> -if (ret < 0) {
>> -err = ret;
>> -goto out;
>> -}
>>  if (ret & LPT_SCAN_ADD) {
>>  /* Add all the nodes in path to the tree in memory */
>>  for (h = 1; h < c->lpt_hght; h++) {
>>
>>
>> Now I wonder how this test result should fit to my source code search 
>> pattern.
> 
> I guess there is a loop around this code, so it is reachable from itself.

* How can we achieve progress with such a bit of information?

* Should such false positives be avoided anyhow?

* Will answers to other questions become more helpful again?

* Are there further development challenges to consider for the safe 
identification
  of unique statements by metavariables?

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

Re: [Cocci] Comparing statement lists with SmPL

[SF Markus Elfring]

>>> Can the search for duplicated source code be improved by the means of the
>>> semantic patch language?
>>
>> For two statements at least you could do:
> 
> An other SmPL script variant can work to some degree.

How do you think about the relevance of the SmPL construct “<+... ...+>”
for this use case?


I tried my intermediate SmPL script variant a bit more.

Example:

elfring@Sonne:~/Projekte/Linux/next-patched> git checkout next-20170803 && 
spatch.opt ~/Projekte/Coccinelle/janitor/show_same_statements3.cocci 
fs/ubifs/lpt.c
…
@@ -1974,10 +1974,6 @@ again:
int ret, lnum = lprops->lnum;
 
ret = scan_cb(c, lprops, path[h].in_tree, data);
-   if (ret < 0) {
-   err = ret;
-   goto out;
-   }
if (ret & LPT_SCAN_ADD) {
/* Add all the nodes in path to the tree in memory */
for (h = 1; h < c->lpt_hght; h++) {


Now I wonder how this test result should fit to my source code search pattern.
I find also more results questionable for this Linux software module.
It seems that there are only two functions which would be an acceptable match.

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

Re: [Cocci] Improving size determinations with SmPL

[SF Markus Elfring]

>> ... when any should be <...
> 
> I have told you exactly what to do here.

You are right in the sense that I misinterpreted your change suggestion.


> The line above currently contains ... when any.  It (and only it) should be
> completely removed and changed to <...

But I find it inappropriate to enclose the function call code by an optional
SmPL nest construct.


> Nowhere do I suggest to put <... ... when any ...>

The suggested script variant seems to work finally.
Thanks for your information.

@replacement@
identifier action, var, work;
type T, X;
@@
 T work(...)
 {
 ... when any
 X* var;
 <...
 var = action(...,
  sizeof(
-X
+*var
),
  ...
 )
 ...>
 }


Now I wonder why the SmPL construct “<+... ...+>” does not produce the same
transformation result for the source file “fs/pstore/ram.c”.

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

Re: [Cocci] Improving size determinations with SmPL

[SF Markus Elfring]

>>> ... when any should be ...>
>>
>> I am unsure if I interpret your suggestion correctly.
> 
> No.  Go read the original message again. It says exactly what to do and
> where it should be done.

Your hint might be nice.


> Eg, my message has two comments, but you have made three changes, which is 
> not correct.

I have tried out to convert the SmPL ellipsis into the optional dot variant.

But I wonder still about the error message “minus: parse error:”
for an adjusted SmPL script variant.

@replacement@
identifier action, var, work;
type T, X;
@@
 T work(...)
 {
 ... when any
 X* var;
 <... ... when any ...>
 var = action(...,
  sizeof(
-X
+*var
),
  ...
 )
 <... ... when any ...>
 }


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

Re: [Cocci] Improving size determinations with SmPL

[SF Markus Elfring]

> ... when any should be ...>

I am unsure if I interpret your suggestion correctly.


@replacement@
identifier action, var, work;
type T, X;
@@
 T work(...)
 {
 <... ... when any ...>
 X* var;
 <... ... when any ...>
 var = action(...,
  sizeof(
-X
+*var
),
  ...
 )
 <... ... when any ...>
 }


elfring@Sonne:~/Projekte/Linux/next-patched> git checkout next-20170803 && 
spatch.opt ~/Projekte/Coccinelle/janitor/safer_size_determination2.cocci 
fs/pstore/ram.c
…
minus: parse error: 
  File 
"/home/elfring/Projekte/Coccinelle/janitor/safer_size_determination2.cocci", 
line 7, column 6, charpos = 80
  around = '...',
  whole content =  <... ... when any ...>



> You request that the sizeof appear on every execution path.

I hope not. - I would like to express that this operator can appear for
a parameter of a function call.

Does the variable declaration “struct persistent_ram_zone *tmp_prz, *prz_next;”
in the function “ramoops_pstore_read” trigger challenges for the attempted
source code transformation?

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

[Cocci] Improving size determinations with SmPL

[SF Markus Elfring]

Hello,

I have constructed the following small script for another application of the
semantic patch language.


@replacement@
identifier action, var, work;
type T, X;
@@
 T work(...)
 {
 ... when any
 X* var;
 ... when any
 var = action(...,
  sizeof(
-X
+*var
),
  ...
 )
 ... when any
 }


I know that this transformation approach is working to some degree.
I came along another source file where I do not get the desired code adjustment
with the software version “1.0.6-00186-g0acd38ee” automatically.

elfring@Sonne:~/Projekte/Linux/next-patched> git checkout next-20170803 && 
spatch.opt ~/Projekte/Coccinelle/janitor/safer_size_determination1.cocci 
fs/pstore/ram.c


How should the software situation be changed further so that the function
“ramoops_pstore_read” will be also handled in the way like I published it in 
the update suggestion “pstore: Improve a size determination in three functions”?
http://elixir.free-electrons.com/linux/v4.12.8/source/fs/pstore/ram.c#L291
https://patchwork.kernel.org/patch/9904523/
https://lkml.kernel.org/r/<23798ef4-5559-3454-ecf4-e6844b644...@users.sourceforge.net>

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

Re: [Cocci] Coccinelle: add atomic_as_refcounter script

[SF Markus Elfring]

Dear Elena,

Why do you insist to use the variables “fname2” till “fname6” in
this evolving SmPL script (instead of merging them into a single one
with a special constraint)?

How do you think about to omit the cover letter for the addition
of such a script (when the change log can be integrated into
the same message for your update suggestion)?

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

Re: [Cocci] Comparing statement lists with SmPL

[SF Markus Elfring]

>> Can the search for duplicated source code be improved by the means of the
>> semantic patch language?
> 
> For two statements at least you could do:

An other SmPL script variant can work to some degree.

@duplicated_code@
identifier work;
statement s1, s2;
type T;
@@
 T work(...)
 {
 ... when any
*if ((...) < 0)
*{
*   s1
*   s2
...
*}
 ...
*if ((...) < 0)
*{
*   s1
*   s2
...
*}
 ...
 }


But matched statements will not be mapped to the discussed metavariable type
in this use case.
I am curious on how such an approach can be used for corresponding source
code transformations.

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