>> * 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
>> 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, p
>>> 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 us
>> ... 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 inappropriat
>>> ... 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 i
> ... 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
+
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
+
>> 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)?
>
> I am pretty new to Coccinelle
This is fine. I am curious then how your interests will evolve further
in this software area
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 in
>> elfring@Sonne:~/Projekte/Coccinelle/janitor> spatch.opt
>> show_same_statements2.cocci ../Probe/hdsp-excerpt1.c
>
> There is no way that I can understand the problme without having the .c file.
I attached this one to a clarification request on the topic
“Improving exception handling a bit wit
>> 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 a
> Unfortunately, the software version “1.0.6-00186-g0acd38ee” does not like this
> SmPL specification.
I overlooked to add parentheses in my evolving SmPL script.
@duplicated_code@
identifier work;
statement s1, s2;
statement list sl;
type T;
@@
T work(...)
{
... when any
(
*if ((...) < 0) {
*
>> 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:
>
> (
> {
> s1
> s2
> ...
> }
> &
> {
> sl
> }
> )
I constructed another SmPL script based on this suggestion as follows.
@duplicated_code@
iden
> It's fine, A statement list just needs { } around it.
How much does this aspect influence a source code search when relevant source
files
do not contain extra curly brackets?
Regards,
Markus
___
Cocci mailing list
Cocci@systeme.lip6.fr
https://syste
> However they can only be bound to the complete sequence of statements in a
> block. So
>
> @@
> statement list sl;
> @@
> if (x) {
> sl
> }
>
> is ok, but
>
> @@
> statement list sl;
> @@
> if (x) {
> one();
> sl
> two();
> }
>
> is not.
How do you think about the usage of a simila
>> Now I am looking for a way to express the constraint that the statement list
>> metavariable should match only source code with two statements at least.
>> Can the search for duplicated source code be improved by the means of the
>> semantic patch language?
>
> For two statements at least you c
> The source code analysis results look promising by this command.
I have just noticed that an other source file points details out for further
development considerations around the mentioned functionality from the
Coccinelle software.
elfring@Sonne:~/Projekte/Linux/next-patched> git checkout nex
>> * How can be determined how many code is equivalent between two statement
>> list variables?
>
> I guess you can make special cases, for one statement, two statements, etc.
I guess that we would like to avoid such an approach for some use cases.
I hope that there are safer programming possibi
>> Is this programming interface usable to determine if any code could be
>> combined
>> to some degree?
>
> I don't really understand the questions.
I try again to describe the use case I became interested in a bit more.
> Statement list metavariables can be used once they are bound like any
Hello,
The Coccinelle software supports metavariables with the type “statement list”.
Can statement lists be compared if they refer to the same source code
structures?
Is this programming interface usable to determine if any code could be combined
to some degree?
Regards,
Markus
> Elena, please don't follow Markus's suggestion.
I suggest to consider additional software development possibilities.
We have got recurring different opinions around the application of advanced
regular expressions.
> Coccinelle doesn't interpret regular expressions when selecting code to work
Dear Elena,
Would you like to take another look at my development suggestion for your
approach?
https://systeme.lip6.fr/pipermail/cocci/2017-August/004300.html
How do you think about to refactor another rule like the following?
@r3 exists@
expression E;
identifier I=~"^atomic(?:64|_long)?_add_r
Dear Elena,
I have also taken another look at your script.
The SmPL rule “r1” specifies six metavariables for identifiers. It seems that
the names “fname3” till “fname6” do not care for different function parameters
in the SmPL disjunction at the end.
How do you think about to reduce this disjunc
> So I get the impression that an other build approach will be safer there.
> How do you think about to add a dependency specification so that interface
> descriptions will be always compiled before the corresponding OCaml code?
I showed change possibilities which can improve the software situatio
> Why do I get such an error message for a parallel software build attempt
> when the specified dependencies worked as expected for the non-parallel
> build try before?
How do you think about the corresponding update suggestion
“Improve some dependency specifications in make rules”?
https://github
> The OCaml makefile specifies an order in which the files should be
> compiled in the project. If you are sidestepping that ordering, then you
> are not doing things in the intended manner.
I hope that some details were clarified to some degree in the meantime.
> There is only an intent to sup
> OK, I don't undertand what command you are doing to get the problem,
Did we achieve a better common understanding in the meantime?
> so I can't reproduce it, so I can't determine whether it is a real issue.
* Are you really keen to achieve this also in your own test environments?
* How much
> The command “ocamldep *.mli *.ml > .depend” was performed for
> relevant subdirectories.
> Unfortunately, this approach seems to be insufficient for the desired
> safe integration of dependency information so far.
I have got another idea. The adjustment results were more promising for my
build s
>> Can you get the impression from the mentioned error message examples
>> that the desired software build prerequisites failed anyhow?
>
> Something fails in your situation, but without knowing the arguments to
> the compiler, I don't know what.
You could know also from the reduced information.
>> Do I stumble on unexpected software behaviour by the tool “GNU Make
>> 4.2.1-1.7”
>> on my openSUSE Tumbleweed system?
>
> Since you don't the complete command line, I have no idea whether the
> behavior is expected or not.
Can you get the impression from the mentioned error message examples
> The command “ocamldep *.mli *.ml > .depend” was performed for
> relevant subdirectories.
> Unfortunately, this approach seems to be insufficient for the desired
> safe integration of dependency information so far.
How do you think about to work any more with dedicated files
for each source file
>> I showed how I could stumble on open issues.
>
> No you didn't.
I try then once more to help you to interpret the mentioned
error message examples.
The command “ocamldep *.mli *.ml > .depend” was performed for
relevant subdirectories.
Unfortunately, this approach seems to be insufficient for
> OK, I don't undertand what command you are doing to get the problem,
I showed how I could stumble on open issues.
> so I can't reproduce it, so I can't determine whether it is a real issue.
There are chances for the reproduction if you would also dare to fiddle
more with the build scripts (an
>> These messages indicate reasons why I am also fiddling with the build scripts
>> for this software again.
>
> These command lines contain ... so I can't see what is being done.
I find the passed concrete parameters which I intentionally left out for
the really desired clarification not so inte
>> I am curious on how a dependency for a software interface like
>> “Visitor_ast0_types”
>> should be expressed for so many source files in a consistent way.
>
> What problem are you trying to solve?
I would like to achieve something more for the topics which were also registered
in the issue t
> If you have changed things, then perhaps you have caused the problem?
I have found an approach for the adjustment of affected build scripts
where I can improve the involved dependency specifications in a few
subdirectories on my own to some degree.
But I guess that a directory like “parsing_cocc
> If you have changed things, then perhaps you have caused the problem?
This is also another possibility in principle.
It seems that I wonder again why some source files should be compiled without
interface description files there.
An other script variant showed the following result.
elfring@
> So I get the impression that an other build approach will be safer there.
> How do you think about to add a dependency specification so that interface
> descriptions will be always compiled before the corresponding OCaml code?
Hello,
I have achieved another bit of progress with my attempt to re
Hello,
I have achieved a bit of progress with one experiment for build script
adjustments.
I would like to try further changes out. Unfortunately, I stumbled on an error
message like the following from the program “GNU Make 4.2.1-1.7” then.
…
/usr/bin/ocamlopt.opt …
File "cocci.ml", line 1:
Erro
>> Can it become safer and more convenient to handle assignments here?
>
> I have no idea what you are asking for.
I wonder about such a kind of feedback.
> In any case, an expression metavariable already matches a variable.
This information can be appropriate in some source code situations.
> var = action(...);
This specification looks also simple for the semantic patch language
at first glance.
I tried to express that a specific value is assigned to something.
But this “something” could be a different item depending on the position
in the source code.
1. Variable
2. Expression
3.
> var = action(...);
> if (failed(var))
This SmPL specification contains a few further software development challenges.
1. It could be taken into account that a function call and a corresponding check
for the return value are not directly next to each other.
A SmPL ellipsis could be added
> How can the Coccinelle software help any more in such an use case?
This small SmPL script example demonstrates two special selections of functions
by their name. They belong to separate categories then.
* The primary actions should usually provide a return value somehow.
* A call of a function
I would like to clarify the possibilities for corresponding software extensions
a bit more.
The Coccinelle software provides also the search operator “question mark” which
denotes code on a specific line as optional.
https://github.com/coccinelle/coccinelle/blob/9b5e00862900b0daadf1819a6894d31544a3
Hello,
I would like to check the implementation of exception handling in various
source files. The following script for the semantic patch language tries to
express a few possibilities for such a source code search pattern.
@show_special_reactions@
expression error_code, var;
identifier action =
>> I find it just strange that extra parentheses are needed in such an use case
>> at the moment.
>
> ... is used in a number of contexts in SmPL, and sometimes its use has to
> be restricted to avoid parsing ambiguities.
I tried to use extra parentheses for other source code search patterns.
I l
>>> Maybe put parentheses around the second argument. An isomorphism will
>>> drop them and you will avoid whatever parsing issue is being encountered.
>>
>> I do not observe a desired improvement after such a SmPL code adjustment.
>
> Your change is not what I suggested either. The second argum
> Maybe put parentheses around the second argument. An isomorphism will
> drop them and you will avoid whatever parsing issue is being encountered.
I do not observe a desired improvement after such a SmPL code adjustment.
@find@
expression target;
identifier action;
@@
target = action(...,
Hello,
I would like to check also the application of elements which are used together
with binary operators like the following.
@find@
expression target;
identifier action;
@@
target = action(...,
...
*| __GFP_NOFAIL
| ...,
...)
> This script finds instances of allocate and memset which can be
> replaced with a direct call to zalloc equivalent of a function.
What is the software development status for this SmPL script in comparison
to an other directory for source code transformations?
https://git.kernel.org/cgit/linux/ke
> The comm_assoc isomorphism allows A || ... to match any disjunction where
> A appears at the top level, not just in the far left position.
Thanks for your explanation.
Are there further software development challenges to consider around the
handling
of items like position variables and “mixed
> elfring@Sonne:~/Projekte/Coccinelle/janitor> spatch.opt
> replace_kcalloc_by_memdup_user-draft1.cocci ../Probe/user_sdma-excerpt1.c
> …
> refactoring: position variables or mixed modifs interfere with comm_assoc iso
> bool (bool !to
> >>> IS_ERR(to)
> || ...)
> …
Would you like to explain th
Hello,
I came along another function implementation where I got the impression that
the function “memdup_user” could also be used there in a way which is similar
to an existing source code transformation approach by a small script for
the semantic patch language.
SmPL script:
https://git.kernel.o
Hello,
I have tried the following small script out for the semantic patch language.
@show_assignments@
expression target;
identifier code =~ "^E[A-Z]+$";
statement is, es;
@@
*target = -(code);
if (...)
is
else
es
elfring@Sonne:~/Projekte/Linux/next-patched> spatch.opt -timeout 23 -j
> Is there a clever way of conditionally making this change?
The answer depends on your desire how “clever” (or sophisticated) an other
approach
should become.
You could try to work with more disjunctions and rules in the semantic patch
language.
This transformation might trigger a few target c
>> need to put another copy of that at the end of the rule with ? in front
>> of it. So that it stops when it comes to that again.
>
> And now it's working just fine.
I became also curious on how the discussed source code transformation can
really work. I imagine that there are still some softwa
> Why were you looking for such functions in the first place?
These functions provide various return values. I am curious on how often
the returned values will actually be checked and used (or not).
> If you want non-static non-void functions and you find them,
> then what is the issue?
NetBSD
Hello,
I tried the Coccinelle software out for another source code analysis approach
on source files from NetBSD 7.0.2.
A small SmPL script worked mostly so good that 136978 non-static function
implementations were finally found with a non-void return type there.
* Can such an analysis result tri
> It seems to be a problem with python initialization only.
Thanks for such a feedback.
> Please do the same.
Your SmPL script example is smaller (than mine) and is sufficient to some
degree for the clarification of desired software initialisation behaviour.
Regards,
Markus
___
>> Can you generally clarify current consequences from usage of a SmPL rule
>> “initialize:…”
>> together with the parameter “--jobs” for the program “spatch”?
>
> It should happen only once.
Thanks for this information.
I would like to know if the script initialisation should happen for each
b
> Without having the semantic patch and the .c file, ideally with both
> cut down to a minimal version that shows the problem,
> I can't answer this question.
Can you generally clarify current consequences from usage of a SmPL rule
“initialize:…”
together with the parameter “--jobs” for the progr
>> Is it really appropriate that this header appears so often in the shown
>> output file?
>
> Without having the semantic patch and the .c file, ideally with both
> cut down to a minimal version that shows the problem,
> I can't answer this question.
Does the follow display look a bit better?
Hello,
I noticed some software development progress for an issue like “SmPL constraints
are broken for type metavariables.”.
https://github.com/coccinelle/coccinelle/issues/32
Now I am checking further test results from a command like the following
for the software combination “Coccinelle 1.0.6-
> disable optional_storage
Thanks for your hint.
* How do you think about to expose more information around this special setting
for
the handling of “annotations” by the semantic patch language together with
“Coccilib”?
* Would it make sense to specify any SmPL constraints for storage-class
> I have no idea what you are talking about.
I got the impression that recent extensions for the Coccinelle software could
increase the chances to update the support for special constraints a bit more.
> What is wrong with the rule that is shown?
This SmPL specification is still working for a w
Hello,
I am using the following bit of code for semantic patch language scripts.
…
@find_static depends on safety_check@
identifier safety_check.work;
position safety_check.pos;
@@
static void work@pos(...)
{
...
}
…
The Coccinelle software was extended for the handling of special constrai
>> @find_…@
>> expression ex1, ex2, value;
>> identifier action =~ …;
>> @@
>> *ex1 = action(...);
>> ex2 = value;
>>
>>
>> I am unsure if such a source code search approach should eventually be split
>> into more SmPL processing steps.
>
> (
> ex1 = action(...);
> ex2 = <+...ex1...+>;
> |
> *ex1
> (
> ex1 = action(...);
> ex2 = <+...ex1...+>;
> |
> *ex1 = action(...);
> ex2 = value;
> )
>
> is perhaps what you are looking for.
I would prefer an approach where the expressions “ex1” and “value” could be
compared
somehow directly instead of matching an unwanted branch in a SmPL disjunctio
> Why don't you think about it on your own and write back if you
> don't figure anything out.
I am still looking for ways to make a small SmPL specification like the
following
a bit safer.
@find_…@
expression ex1, ex2, value;
identifier action =~ …;
@@
*ex1 = action(...);
ex2 = value;
I am un
> Normally, if you want to prevent something, the easiest thing is to match
> it first, and then set up the pattern for what you want so that the latter
> matches only if the former did not match.
Is my use case a bit more special so that other approaches would be needed?
Would another constraint
Hello,
I am experimenting with another source code search pattern. This approach
pointed a place like the following out for further considerations.
…
ice->akm = kcalloc(…);
ak = ice->akm;
…
My evolving SmPL script used also two separate metavariables with the
type “expression” s
> Why not just define a python function that you can call in a script to do
> your big regexp for you?
Would any more developers and reviewers like to extend a source code analysis
approach with a regular expression (or other data structure) like the following?
SmPL script example:
@initialize:p
>> Do you find the documentation complete for this functionality at the moment?
>
> No idea.
How can we achieve a better common understanding on this aspect for example?
>> I imagine a need for advanced configuration possibilities around “regexp”
>> engines.
>
> You imagine many things.
Yes,
> I don't think there is anything to be more explicit about.
Do you find the documentation complete for this functionality at the moment?
> I don't foresee any change in the regular expression syntax,
I imagine a need for advanced configuration possibilities around “regexp”
engines.
> and I
>>
>> https://github.com/coccinelle/coccinelle/commit/cbc751b30d9e02390d60ebed643c8e4a3fa0bb2b
>>
>>But I am unsure about their current development and documentation status.
>>Are there any more imaginations floating around for the notation and usage
>>of named (or ad hoc) predicate
Hello,
I tried another source code search pattern out with the semantic patch language
from the software “Coccinelle 1.0.6-00022-g862f5b29 (OCaml 4.03)”.
SmPL script example:
@find_too_late_checking@
expression assign1, assign2, ex1, ex2;
identifier action1 =~ "^(?x)
(?:
k(?:[cmz]alloc|(?:m(
>> But can it be that this assignment is checked a bit too late?
>
> Yes,
Thanks that you can agree to such a view.
> but no one will care.
I am curious if further software development opinions will appear around
similar situations.
> The code is more concise as is.
I have got an other opin
>> elfring@Sonne:~/Projekte/Coccinelle/janitor> spatch.opt
>> show_too_late_checking2.cocci ../Probe/clk-mstp-excerpt1.c
>> init_defs_builtins: /usr/local/lib64/coccinelle/standard.h
>> HANDLING: ../Probe/clk-mstp-excerpt1.c
>> diff =
>> --- ../Probe/clk-mstp-excerpt1.c
>> +++ /tmp/cocci-output-20
> Now I wonder why the first assignment is not marked together with the
> function call
> for further considerations by my source code analysis approach so far.
I should have adjusted one of the used regular expressions a bit more like the
following.
@find_too_late_checking@
expression ex1, ex
Hello,
I would like to try another search pattern out with the semantic patch language
from the software “Coccinelle 1.0.6-00022-g862f5b29 (OCaml 4.03)”.
SmPL script example:
@find_too_late_checking@
expression ex1, ex2;
identifier action1 =~ "^(?x)
(?:
kzalloc
| kmalloc_array
)$",
> No interest in supporting either.
This is a pity at the moment.
Are there any other software development concerns involved which result
into such a rejection?
> How are these so vastly better than:
>
> @initialize:python@
> @@
> def is_watched(id):
> return id in ['a', 'c']
>
> @structu
>> https://github.com/coccinelle/coccinelle/blob/cbc751b30d9e02390d60ebed643c8e4a3fa0bb2b/tests/idcon_python.cocci#L1
>
> The syntax is curly brackets around a C expression.
I do not understand this information completely at the moment.
>>> Concretely, the script constraint code is initially pa
>> Does the script constraint syntax allow more programming language code there?
>
> For all practical purposes, no.
If you would like to be so strict, I wonder then about the curly brackets
in the published test example.
https://github.com/coccinelle/coccinelle/blob/cbc751b30d9e02390d60ebed643c8
>> * Would such an inclusion approach trigger special requirements on the
>> position for corresponding initialisation code?
>
> The constraint specification should be a single function call.
Does the script constraint syntax allow more programming language code there?
> You can set up your @
> The idea with the script constraints on metavariables feature is that the
> script code there should only contain a function call. The actual
> function definition should be elsewhere; probably in an initialize rule.
* Did you consider the use case already when such a constraint specification
> The idea with the script constraints on metavariables feature is that the
> script code there should only contain a function call.
I would like to add another view to this software evolution for
further considerations.
The purpose of such a function call can be interpreted in different ways,
can
>
> The idea with the script constraints on metavariables feature is that the
> script code there should only contain a function call. The actual
> function definition should be elsewhere; probably in an initialize rule.
This information can be reasonable to some degree.
How will the software si
>> I am looking for ways to avoid source code duplication by inclusion of
>> other files.
>> Would it make sense to allow the use of an include statement within the
>> SmPL variable definition block of a rule?
> I have the impression that what you want would be adequately implemented
> by a virtua
>> Can other SmPL rule types specify constraints in the code form of a
>> regular expression or a programming language script?
> At the moment, the specification of constraints is not very uniform across
> the different metavariable types. We are working on improving this.
* Have you got any time
> In a script rule, the metavariable declarations are interpreted by Coccinelle,
> not the scripting language, so an include would not be allowed there.
This detail was clear for me in principle.
> Script rules also don't have constraints on metavariables anyway,
Can other SmPL rule types speci
Can such initialisation code be constructed by the specification of several
script parts there?
>>> I don't understand the question.
>> I suggest to consider corresponding design consequences again.
>>
>>
>>> If the script language supports includes, then you can put includes in the
>>>
> I don't understand what it would mean for syntax to or not to matter.
I am checking if the mentioned SmPL statement could be used just for the
inclusion of a bit of code for a metavariable constraint within a script
template.
> The main issue seems to be that the includes can only appear befor
>> Can such initialisation code be constructed by the specification of several
>> script parts there?
>
> I don't understand the question.
I suggest to consider corresponding design consequences again.
> If the script language supports includes, then you can put includes in the
> script code.
>> * Can SmPL rules be constructed from smaller parts by it?
>
> I don't understand what it would mean for syntax to or not to matter.
I am curious if the included data need to be usable also alone in the
SmPL sense.
> The main issue seems to be that the includes can only appear before the norm
Hello,
The semantic patch language supports also extra data processing by
initialisation scripts.
http://coccinelle.lip6.fr/docs/main_grammar003.html
Can such initialisation code be constructed by the specification of several
script parts there?
Regards,
Markus
__
Hello,
The semantic patch language supports also the inclusion of external files.
http://coccinelle.lip6.fr/docs/main_grammar001.html
* Does syntax matter for this SmPL statement?
* Can SmPL rules be constructed from smaller parts by it?
Regards,
Markus
_
>> I assumed that the reduced code repetition could result in a desired effect.
>
> Incorrect on all points.
I wonder then why the Coccinelle software would not benefit from the
specification of common parts in two similar SmPL disjunctions.
Regards,
Markus
__
> Sorry, I thought it was the original code, and didn't realize that it was
> the suggestion..
>
> But I don't think that the suggestion improves readability in any way.
I hoped that my SmPL script variant could influence the execution
characteristics
in positive ways.
> Coccinelle disjunction
> What do you mean by "a bit more fine-tuning"? If you have a concrete
> suggestion, then make it. But don't make work for other people to guess
> what you might mean.
I hoped that the SmPL source code below would explain my update suggestion
in a sufficient way to use two smaller SmPL disjuncti
Dear Vaishali,
You sent an update suggestion for the source file
“scripts/coccinelle/misc/irqf_oneshot.cocci”
on 2016-10-16.
It contained a patch hunk like the following.
@@ -32,20 +31,39 @@ IRQF_ONESHOT
|
devm_request_threaded_irq@p(dev, irq, NULL, thread_fn,
(
-flags | IRQF_ONESHOT
+IRQF_
1001 - 1100 of 1817 matches
Mail list logo
