> 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@
>> 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
> 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
>> * 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
>> 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
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
> 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
> 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”?
> 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
> 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
>> 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.
> 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
>> 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
> 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
> 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.
> 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
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:
>> 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
> 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
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.
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
>>> 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
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?
> 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
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:
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
> 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
>> 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
> 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
>> 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
> 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
>> 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
> 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
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
> (
> 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
> 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
> 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:
>> 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.
> 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)
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)
(?:
>> 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
> 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,
>> * 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,
>
> 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
> 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
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
>>>
>> 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.
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
>> 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
> 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
>> How much would you like to increase the support for data processing around
>> macros
>> with your software?
>
> Ther are no particular plans in this direction.
How does this kind of feedback fit to an information like “Add identifier list
metavariables
for #define parameter lists” from the
>> I have got a few concerns for further software development considerations.
>> How do you think about to support also an advanced interface by which it
>> could be
>> determined if a preprocessor symbol would correspond to such a desired
>> character
>> (instead of fiddling with regular
>> Will it occasionally matter then to distinguish better if a specific source
>> code
>> fragment or a complete source file should be excluded from an analysis run
>> on demand?
>
> I have no idea what you mean by this.
I assume that there are more chances.
I am just unsure around the
>> I do not see the way so far how desired data could be extracted from a
>> function
>> (or expression?) parameter. Would you like to make the introspection options
>> a bit
>> clearer for the SmPL interface?
>
> You can inherit and test properties of anything you like in python or ocaml
>
> You can look at patches people have previously submitted and see to what
> extent there is interest in this issue.
I see another software development challenge here.
The discussed source code search pattern builds on a "general function"
like "seq_printf" as an update candidate from which each
> You can inherit and test properties of anything you like in python or
> ocaml code. If you inherit some kind of metavariable other than a
> position variable, the term will be represented as a string. But that
> should be fine for detecting eg if a string has only one character.
Your
>> With which metavariables and corresponding programming interfaces can
>> strings that
>> are passed to such functions be checked in more detail by the Coccinelle
>> software?
>
> The simplest would be to use python or ocaml code to make the checks that
> are needed. You can use
Hello,
I came during my software development activities along a few Linux source files
where I got an advice by the script "checkpatch.pl" like the following.
WARNING: Prefer seq_puts to seq_printf
>>> The only effect your emails had on me was a big "WTF!?".
>>
>> All of them (including the provided small SmPL script examples on
>> 2016-10-05)?
>
> You wrote three emails on that day. I assume you mean this one?
There are further possibilities to improve your learning experience around
the
>>> Someone who has to read so much text and in the end has no information
>>> about the question he was asking will not likely get a good impression
>>> about the software he is trying to use.
>>
>> A beginner should usually read some text for the desired learning experience.
>> Can it be that
>> The name is illustrated in Advanced SmPL:
>> http://coccinelle.lip6.fr/papers/cocciwk4_talk2.pdf
>
> Call me stupid, but I just went through it again and I still don't see
> it. There are lots of examples with "@ ..stuff..@" (the first on slide
> 4), but as far as I can tell it never explains
> I'm not angry at all,
Thanks for your feedback that there are other emotions involved.
> only tired of so much incorrect
Which details from my description approach are inappropriate in your view?
> or unnecessary information being provided to new users.
I got the impression somehow that
>>* Syntax constructs from the supported source languages are matched with
>> "key words" that are often similar (or even identical) to the host
>> language
>> (within SmPL scripts).
>
> This is an enormous amount of verbiage,
Interesting view …
> and I don't see the relevance
> To me, an identifier is something that's written literally into the
> source code and cannot be meaningfully taken apart, e.g. a function
> name, variable name, or the member of a struct. An expression, on the
> other hand, is something that can be meaningfully split into
> sub-components. Is
> Do I overlook any commit for the discussed source file anyhow?
> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/log/dev-tools/coccinelle.rst
It seems that I missed this file also because an other path will be appropriate.
>>> Information from a commit like "docs: sphinxify coccinelle.txt and add it
>>> to dev-tools" caught also my software development attention.
>>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/Documentation/coccinelle.txt?id=4b9033a33494ec9154d63e706e9e47f7eb3fd59e
>>>
>>>
> Either you send the patch, or I will send the patch, when I have time,
> with no credit to you.
I am curious when "the time" will be appropriate.
> I'm not an expert on all of the future plans for the documentation,
I assumed that you know a bit more about the corresponding software
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/scripts/coccicheck?id=c802e87fbe2d4dd58982d01b3c39bc5a781223aa#n4
>>>
>>> How about submitting a patch to fix the problem?
>>
>> I would appreciate to become a bit more sure about the current storage
>> location
>> which
>> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/scripts/coccicheck?id=c802e87fbe2d4dd58982d01b3c39bc5a781223aa#n4
>
> How about submitting a patch to fix the problem?
I would appreciate to become a bit more sure about the current storage location
which should be
Hello,
Information from a commit like "docs: sphinxify coccinelle.txt and add it
to dev-tools" caught also my software development attention.
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/Documentation/coccinelle.txt?id=4b9033a33494ec9154d63e706e9e47f7eb3fd59e
Did an
>> @name_replacement@
>> @@
>> my_type *
>> -ptr
>> +pointer
>> ;
>
> I could try it, but I'm actually more interested in understanding how
> this works (I already solved my primariy problem).
Thanks for your interest.
> Could you explain this script a bit more?
Yes, of course.
It shows
> 2. ..and how would I go about if instead of the type, I want to replace
>a variable name? (my_type *ptr --> my_type *pointer).
Would you like to try another small SmPL script out like the following?
@name_replacement@
@@
my_type *
-ptr
+pointer
;
How will your software development
> Based on the LWN articles that I've read, this seems like the perfect
> use-case for coccinelle.
I would expect this also if you are interested in the simple replacement
for the data type of a function parameter.
> However, somehow I'm struggling to write a patch for this.
Are you exploring
> One more, I use 1.0.2 version as I had a problem with 1.0.5
> compilation previously.
Thanks that you added a bit more version information to your bug report.
> I will try bump to 1.0. 5 anyway and check the behavior.
Thanks for your interest to try additional software variants out.
I have
> It goes into the directory specified with the --tmp argument.
Does the software process "Compilation of PQL into SmPL" generate
any disjunctions (and conjunctions) into the corresponding SmPL source code?
Regards,
Markus
___
Cocci mailing list
> Is it possible to detect such code patterns (multiplication operation
> followed by division to check for overflow) which invoke undefined
> behavior using Coccinelle?
I imagine that it is generally possible to find some update candidates
for such an use case also by means of the semantic patch
>>* How much will the data format flexibility evolve together with the
>> handling
>> of a key word like "flexible" for metavariables?
>
> No idea what this means (data format flexibility).
Is this key word the only one which was added to "PQL" (while it is processed by
"SmPL" in other
> Prequel is like Coccinelle, but for searching in Git commit histories.
I am curious on how this software approach will evolve further.
> http://prequel-pql.gforge.inria.fr/
>
> Feedback is welcome.
I pick your offer up now.
Thus I have read your research report 8918 (Prequel: A Patch-Like
> With the 4.8-rc1 kernel, when I run Coccinelle check using the command “make
> coccicheck MODE=report M=”,
> I get “coccicheck failed” message. I get the same failure message even with
> “MODE=patch”
> in the command.
I noticed this error message also.
There are further software
@vz_combined
depends on patch && !context && !org && !report@
type T;
T* pointer;
+statement S;
expression express;
@@
pointer =
- vmalloc
+ vzalloc
(...);
if (!d)
S
-memset(d, 0, sizeof(
>> How do you think about the following SmPL script example?
>>
>> @vz_combined
>> depends on patch && !context && !org && !report@
>> type T;
>> T* pointer;
>> +statement S;
>> expression express;
>> @@
>> pointer =
>> - vmalloc
>> + vzalloc
>>(...);
>> if (!d)
>>
>> 1. Would it make sense to merge such SmPL rules into one
>>so that code duplication could be reduced a bit
>>in such a script?
>
> I think it would suffer in readability.
How do you think about the following SmPL script example?
@vz_combined
depends on patch && !context && !org &&
101 - 200 of 611 matches
Mail list logo
