> It's interesting to get the function list automatically.
I occasionally imported code data into list variables
or even database tables.
> I'll try to parse the drivers/of/base.c file based on comments like this
> "* Returns a node pointer with refcount incremented, use
> * of_node_put() on it
://systeme.lip6.fr/pipermail/cocci/2019-March/005692.html
https://lkml.org/lkml/2019/3/26/395
I would appreciate if corresponding implementation details will get
another look.
Markus Elfring (5):
Adjust a message construction
Add a cast to an expression for an assignment
Merge four SmPL when
From: Markus Elfring
Date: Tue, 7 May 2019 11:20:48 +0200
The Linux coding style tolerates long string literals so that
the provided information can be easier found also by search tools
like grep.
Thus simplify a message construction in a SmPL rule by concatenating text
with two plus operators
From: Markus Elfring
Date: Wed, 8 May 2019 13:50:49 +0200
Extend a when constraint in a SmPL rule so that an additional cast
is optionally excluded from source code searches for an expression
in assignments.
Signed-off-by: Markus Elfring
Suggested-by: Julia Lawall
Link: https
From: Markus Elfring
Date: Sun, 12 May 2019 18:32:46 +0200
An assignment target was repeated in four SmPL when constraints.
Combine the exclusion specifications into disjunctions for the semantic
patch language so that this target is referenced only once there.
Signed-off-by: Markus Elfring
From: Markus Elfring
Date: Mon, 13 May 2019 09:47:17 +0200
A SmPL ellipsis was specified for a search approach so that additional
source code would be tolerated between an assignment to a local variable
and the corresponding null pointer check.
But such code should be restricted.
* The local
From: Markus Elfring
Date: Mon, 13 May 2019 09:55:22 +0200
A single parameter was repeated for a function call in two SmPL
when constraints.
Combine the exclusion specifications into a disjunction for the semantic
patch language so that this argument is referenced only once there.
Signed-off-by
From: Markus Elfring
Date: Mon, 13 May 2019 09:47:17 +0200
A SmPL ellipsis was specified for a search approach so that additional
source code would be tolerated between an assignment to a local variable
and the corresponding null pointer check.
But such code should be restricted.
* The local
>> Thus simplify a message construction in a SmPL rule by concatenating text
>> with two plus operators less.
>
> Is there any way to unindent, so that the string doesn't exceed 80 characters,
> or at least no so much?
How does your concern fit to the string literal tolerance from
the Linux coding
>> An assignment target was repeated in four SmPL when constraints.
>> Combine the exclusion specifications into disjunctions for the semantic
>> patch language so that this target is referenced only once there.
>
> NACK.
I find this rejection questionable.
> This exceeds 80 characters
The line
>> An assignment target was repeated in four SmPL when constraints.
>> Combine the exclusion specifications into disjunctions for the semantic
>> patch language so that this target is referenced only once there.
>
> NACK.
I find this rejection questionable.
> This exceeds 80 characters
The line
>> Take additional casts for these code exclusion specifications into account
>> together with optional parentheses.
>
> NACK.
I find this rejection surprising.
> You don't need so many type metavariables.
I got an other software development opinion for this aspect.
Yesterday we started to cla
>> Combine the exclusion specifications into a disjunction for the semantic
>> patch language so that this argument is referenced only once there.
…
> NACK. This hurts readability
I suggest to reconsider such readability concerns once more.
Can corresponding software limitations be adjusted any f
> I realize that you don't like it, although I have no idea why.
> Does it make the code slower?
Would you like to compare the run time characteristics from creating and
looking up an identifier for a Python variable to direct passing of
a concatenated string for the desired function call?
> I t
>> I try to stress SmPL functionality in this use case.
>
> That's not the goal of the semantic patches in the kernel.
>
> The rule is fine as it is.
I am curious under which circumstances other software aspects
can become more relevant (as suggested).
Regards,
Markus
>> A SmPL ellipsis was specified for a search approach so that additional
>> source code would be tolerated between an assignment to a local variable
>> and the corresponding null pointer check.
>>
>> But such code should be restricted.
>> * The local variable must not be reassigned there.
>> * It
>> Can you agree to any information which I presented in the commit message?
Do you find this description inappropriate?
>>> You don't need so many type metavariables.
>>
>> It seems that the Coccinelle software can cope also with my SmPL code
>> addition.
>> You might feel uncomfortable with t
>> Can you agree to any information which I presented in the commit message?
Do you find this description inappropriate?
>>> You don't need so many type metavariables.
>>
>> It seems that the Coccinelle software can cope also with my SmPL code
>> addition.
>> You might feel uncomfortable with t
> I did another experiment at that time and found that this modification will
> reduce the false positive rate,
Thanks for such feedback.
Will my update suggestion influence the current (or future) software situation?
> but it may also reduce the recall rate.
Would you like to explain this inf
This script for the semantic patch language contains implementation details
which can be improved.
Markus Elfring (3):
Use formatted strings directly in SmPL rules
Reduce a bit of duplicate SmPL code
Extend when constraints for two SmPL ellipses
.../coccinelle/free
From: Markus Elfring
Date: Tue, 14 May 2019 16:54:40 +0200
Formatted strings were always assigned to the Python variable “msg”
before they were used in two rules of a script for the semantic
patch language.
Delete these extra variables so that the specified string objects
are directly used for
From: Markus Elfring
Date: Tue, 14 May 2019 17:18:24 +0200
A return statement was specified with a known value for three branches
of a SmPL disjunction.
Reduce duplicate SmPL code there by using another disjunction for
these return values.
Signed-off-by: Markus Elfring
---
scripts/coccinelle
From: Markus Elfring
Date: Tue, 14 May 2019 17:18:24 +0200
A return statement was specified with a known value for three branches
of a SmPL disjunction.
Reduce duplicate SmPL code there by using another disjunction for
these return values.
Signed-off-by: Markus Elfring
---
scripts/coccinelle
From: Markus Elfring
Date: Tue, 14 May 2019 18:12:15 +0200
A SmPL ellipsis was specified for a search approach so that additional
source code would be tolerated between an assignment to a local variable
and the corresponding null pointer check.
But such code should be restricted.
* The local
> NACK. If the code is going to change, I would rather it come closer to
> staying within 80 characters.
Do you really prefer then to deviate from the Linux coding style
at such source code places?
Would you like to split affected string literals over multiple lines?
Regards,
Markus
>> A return statement was specified with a known value for three branches
>> of a SmPL disjunction.
>> Reduce duplicate SmPL code there by using another disjunction for
>> these return values.
…
> NACK. The goak is not to squeeze the most information into the fewest
> number of characters.
Can yo
> 1, "id = (T2)(e)" is rare.
I can follow this view for such a filter.
> It may be a minor detail that will have no impact in practice.
I suggest to reconsider this view once more.
Should such exclusion specifications take also “unexpected” source code
into account so that analysis results wil
> 1, "id = (T2)(e)" is rare.
I can follow this view for such a filter.
> It may be a minor detail that will have no impact in practice.
I suggest to reconsider this view once more.
Should such exclusion specifications take also “unexpected” source code
into account so that analysis results wil
>> Can different run time characteristics become relevant here?
>
> Internally, they should be identical.
I got other imaginations in this area.
I assume that the evaluation of a separate SmPL disjunction
for the shown return values is occasionally nicer than
the repeated matching for the corresp
>> But with your modified SmPL, we can't find the bug.
>
> I do not see a difference here.
I have accidentally overlooked to pass the parameter “-D report”
to the spatch program.
Now I notice also an unexpected and undesirable difference for your test example
after the suggested addition of exclus
> I don't think it is an environmental issue.
You are right about taking other parameters better into account.
> Theoretically, the original SmPL should find bugs.
I expect also that both script versions should display a warning.
> Although, I still send you my environmental information:
Tha
>> 1, "id = (T2)(e)" is rare.
>
> Thanks for checking. I don't really care if it is rare.
I got related source code analysis concerns.
> There should not be much cost to this.
Each additional filter will influence the software run times and
possible results.
> On the other hand, I do care ab
>>> On the other hand, I do care about causing false negatives.
>>
>> Do you find the missing warning after the addition of such an exclusion
>> specification interesting?
>
> I already suggested how to improve the code.
I find that the idea “e2->fld” needs further clarification.
Such a SmPL speci
>> Thanks for such additional information. Is it represented in the software
>> documentation (besides the source code format)?
>
> It is not a concern of the user.
I got interested in corresponding aspects.
> The documentation is not going to contain a description of every line
> in the impleme
> Could we use it to find out as many bugs as possible in the current kernel
How do you think about to work with any more source code analysis approaches?
> and then modify it?
I guess that you do not need to wait for a solution so long.
Variables which get reassigned in unwanted ways (before
> 1, A simple method.
> We did some experiments, and we could get the list of functions that need to
> be considered directly through this script:
>
> $ spatch --tokens-c drivers/of/base.c 2>&1 | grep "Tag3 " | grep
> "of_node_put() on it when done." | awk -F " - " '{print $1}' | grep -o
> "o
> A semantic patch has no access to comments.
Thanks for your acknowledgement of the current situation.
> The only thing I can see to do is to use python to interact with some
> external tools.
I see more software development possibilities.
* Advanced data processing for source code comments
> $ spatch --tokens-c drivers/of/base.c 2>&1 | grep "Tag3 " | grep
> "of_node_put() on it when done." | awk -F " - " '{print $1}' | grep -o
> "of_[[:print:]]*"
This command example points some details out for further software development
considerations.
1. I find it questionable that releva
> On the other hand, I don't know if the one that seemed to cause a crash
> really caused a crash. It was detected by syzkaller, and it is also
> possible that git bisect ended up at the wrong place.
Do you refer to any known bug report here?
> In any case, forgetting an of_node_put will normal
Message repetition from 2019-05-16 because of a temporary technical difficulty
with the mailing list services:
=
Hello,
The semantic patch language can handle several rules which can contain
remarkable amounts of source code search specifications.
It can happen then that a few of these SmPL
>> Can the splitting and recombination of such rules become more convenient
>> with extensions for the Coccinelle software?
>
> In general it can't.
This feedback seems to fit to the current software situation.
> Coccinelle doesn't have the goal of minimizing the number of characters
> in te sem
> It is now possible to match the comments before, within, and after the
> match of a token, via a comments metavariable.
Are there any structures supported within source code comments?
How do you think about to filter any text by regular expressions
for semantic patch language constraints?
Woul
>> How do you think about to filter any text by regular expressions
>> for semantic patch language constraints?
>
> Not supported.
Would the text filter be possible by using (OCaml) script rules so far?
How will these limitations be represented in the software documentation?
>> Would you like t
>> @display@
>> comments C;
>> @@
>> *C
>
> This is not possible.
At the moment.
> Comments metavariables can only be attached to other tokens.
I find that his wording can be ambiguous.
How do you think about views around literate programming
where executable code is between these comments?
R
> You can do whatever you want in the ocaml code.
This programming language has got also a general potential.
But I find that there are special development challenges to consider
for software components which do not belong to its standard library.
How do you think about to take another look at an
> You can do whatever you want in the ocaml code.
How will the following software situation be resolved?
elfring@Sonne:~/Projekte/Coccinelle/20160205> COCCINELLE_HOME=$(pwd)
/usr/local/bin/opam config exec --switch 4.07.1 ./spatch demos/comments.cocci
demos/comments.c
init_defs_builtins: /home/
>> How will the following software situation be resolved?
>
> make distclean
> ./autogen
> ./configure
> make
These commands were executed also on my system yesterday.
> There is no dependency on any particular system compiler version.
Why is the program “ocamlc.opt” looking for the file “/usr/
>> Why is the program “ocamlc.opt” looking for the file
>> “/usr/lib64/ocaml/list.cmi”
>> instead of using the selected variant
>> “~/.opam/4.07.1/lib/ocaml/stdlib__list.cmi”?
>
> OK, I don't know. Either Thierry knows or there is some problem with the
> setup of your system.
Which test results
>> ocamlc.opt -c /tmp/ocaml_cocci_bbc38d.cmo -g -I
>> /home/elfring/Projekte/Coccinelle/20160205/ocaml -I /usr/lib64/ocaml
>> /tmp/ocaml_cocci_bbc38d.ml
Do you know where the include parameters are determined for such a call
of the OCaml compiler in your source code?
Regards,
Markus
__
ocamlc.opt -c /tmp/ocaml_cocci_bbc38d.cmo -g -I
/home/elfring/Projekte/Coccinelle/20160205/ocaml -I /usr/lib64/ocaml
/tmp/ocaml_cocci_bbc38d.ml
>>
>> Do you know where the include parameters are determined for such a call
>> of the OCaml compiler in your source code?
>
> I had no
ocamlc.opt -c /tmp/ocaml_cocci_bbc38d.cmo -g -I
/home/elfring/Projekte/Coccinelle/20160205/ocaml -I /usr/lib64/ocaml
/tmp/ocaml_cocci_bbc38d.ml
>>
>> Do you know where the include parameters are determined for such a call
>> of the OCaml compiler in your source code?
>
> I had no
> @ replace_simple_positive @
How do you think about to move this rule to a separate SmPL script?
Do any other subsequent rules depend on it?
Regards,
Markus
___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci
>> ocamlc.opt -c /tmp/ocaml_cocci_bbc38d.cmo -g -I
>> /home/elfring/Projekte/Coccinelle/20160205/ocaml -I /usr/lib64/ocaml
>> /tmp/ocaml_cocci_bbc38d.ml
How can it be achieved to replace the shown reference to a directory
of the (standard) library for the system OCaml compiler?
elfring@Sonne:
> You get a list of strings, with one comment per string.
It seems that this metavariable provides structured information
which can be split according to your OCaml code in the SmPL script.
“…
let (c1b,c1m,c1a) = List.hd c1 in
…”
Can this programming approach result in undesirable data duplicat
>> * Now I wonder why this display is presented in three variations.
>
> Before within and after
I find this software behaviour hard to understand at the moment
when the shown metavariables were split into three parts already
by the call of the OCaml function “List.hd”.
Which comment would be pro
> There is one in an argument list that is within a statement.
This would only matter for the second call of the function “foo”
in the example function “main”, wouldn't it?
https://github.com/coccinelle/coccinelle/blob/210ce894d2dd1572fff9e1c98ae443e6df14f4c7/demos/comments.c#L2
How does your so
>> “…
>> let (c1b,c1m,c1a) = List.hd c1 in
>> …”
>>
>>
>> Can this programming approach result in undesirable data duplication?
>
> There is no data duplication.
The involved data structures are unclear at the moment.
> Learn about pointers.
How many different pointers will refer to empty strin
>> How does your software decide which comment should be treated
>> as simple text before or after an item?
>
> It takes all of the comments before (up to the preceding non comment
> token if any) within and after (up to the following non comment token
> if any).
I find that this information can b
> There is one in an argument list that is within a statement.
Can it be that such a comment would belong to the function call operator
(open or closing parenthesis) instead of the identifier “foo”?
Regards,
Markus
___
Cocci mailing list
Cocci@systeme.l
Hello,
The OCaml programming language supports also the evaluation of
regular expressions.
* Can the corresponding match (or search failure) be stored in a variable
so that it can be directly used for a dependency specification in
a subsequent SmPL rule?
* Is SmPL variable inheritance suppor
> Parameter lists are irrelevant. That is just an example.
We have got a different understanding for the desired comment handling
there at the moment.
> As long as the SmPL token matches more than one token,
Would we like to distinguish and clarify this case any further?
> it is possible tha
>> How many different pointers will refer to empty strings here?
>
> None. If there is no comment, it will be the empty list.
How many different pointers can occur for these empty items?
> The before, within and after comments are lists of strings.
Will data structures become helpful where les
> You can attach a comment metavariable to any token in the semantic patch.
> some of these are metavariables. Metavariables (except identifier
> metavariables) often match more than one token in the C code.
Can this case distinction trigger corresponding software design adjustments?
How often w
> You can attach a comment metavariable to any token in the semantic patch.
> some of these are metavariables. Metavariables (except identifier
> metavariables) often match more than one token in the C code.
Can this case distinction trigger corresponding software design adjustments?
How often w
>> Will data structures become helpful where less than three attributes
>> would be provided because a special source code element would be selected?
>
> Stop the pointless micro optimization. This has no impact on anything.
We got different programming views which influence another approach
to a
>> How often will it matter if only one item is involved instead of
>> several places?
>
> Your approach introduces pointless complexity to distinguish between th
> different cases.
I got an other software development opinion.
It might take another while to agree on useful case distinctions.
Do a
>> Can it be that such a comment would belong to the function call operator
>> (open or closing parenthesis) instead of the identifier “foo”?
>
> You put the comment metavariable on whatever you want.
This functionality is generally nice.
> The report for the comment in the argument list comes f
>> elfring@Sonne:~/Projekte/Coccinelle/20160205> COCCINELLE_HOME=$(pwd)
>> /usr/local/bin/opam config exec --switch 4.07.1 ./spatch.opt
>> demos/comments.cocci demos/comments.c
>> …
>> c1b: /* before the function … */
>> …
>>
>>
>> * Now I wonder why this display is presented in three variations
>> * How do you think about my expectation that the OCaml script rule
>> should be evaluated only once because a single function implementation
>> example is analysed here?
>
> The multiple times have to do with the ... not the comment variables.
I do not expect so far that the SmPL code “...
> The when any's allow any possible match.
I agree to this technical aspect.
> There are three calls to foo so three possible matches.
I find that this possibility does not require to repeat the evaluation
for the complete OCaml script rule.
I would find a possible repetition eventually reasona
> The when any's allow any possible match. There are three calls to foo so
> three possible matches.
Can my software interpretation of unexpected code repetition be adjusted
also by moving the code “\(foo@c3();\&S@c4\)” into another SmPL rule?
Can it make sense to split the OCaml script rule the
> The before, within and after comments are lists of strings.
I got further software development ideas around the provided data structures.
* If you would like to search within the text of multi-line comments
by the means of regular expressions, the list elements need to be
concatenated befor
Hello,
The semantic patch language supports also the specification and handling
of OCaml script rules. Inherited SmPL variables can be connected to
corresponding local variable names.
I would appreciate if the determination of the provided data structures
can become easier.
* Which data types can
> Besides comments, everything is either a string or a position,
> ie type pos list, where the type pos is found in man Coccilib.
How do you think about to improve the programming interface descriptions here?
Which data structures would be relevant for the metavariable “identifier”?
Do they refer
> Am I missing something?
It depends on details.
Your initial transformation approach can be written also as follows.
@replacement@
identifier x;
@@
-int
+int*
x;
In which scopes would you like to add the asterisk for the usage of a pointer
data type?
Do you expect that function parameters s
>> @replacement@
>> identifier x;
>> @@
>> -int
>> +int*
>> x; >
>>
>> In which scopes would you like to add the asterisk for the usage of a pointer
>> data type?
…
> 1) "x" has a type of "int *"
The asterisk addition seems to work for (local) variables.
> 2) the new "int *x" gets passed to a
> In other words, in my original code "int x" is passed to "void f(int)" as a
> paramter,
> and I would like to apply the following transformations:
How do you think about to try a SmPL change specification out like the
following?
@replacement3@
identifier x;
@@
-int
+int*
x;
<+...
-f
+g
(x
> The issue is that if the rule gets matched in one file,
> it will include the header in every other file as well,
How did you choose the selected source file combination?
> because the "depends on ever" clause is satisfied.
> Is there a way to tell coccinelle "apply this rule to file X,
> but
>> @replacement3@
>> identifier x;
>> @@
>> -int
>> +int*
>> x;
>> <+...
>> -f
>> +g
>> (x);
>> ...+>
>
> His example shows that he wants to change a parameter type,
He would like to call a function which gets a single pointer passed
instead of an integer by possibly varying variables.
> no
> I have this rule, but spatch puts the left brace on the same line as
> if-statement:
…
> How can I fix this?
There are some software development options available.
* Do you expect that the Coccinelle software should pick a coding style up
from the mentioned source files automatically?
* I w
> … But it would be nice if I could control some commonly-used options, …
Thanks for your feedback.
> I don't have anything to contribute other than "I need this feature".
Will any programmers appear who would be willing to contribute
more significant development resources?
Regards,
Markus
___
> I have a feeling that I can use the "when" statement for what I'm
> trying to do in Coccinelle,
Would you like to tell a bit more about your next software transformation needs?
> but I can't figure out how it works.
Can any information from previous discussions around SmPL code exclusion
spec
> Unfortunately, I observed during a few runs on my test system
> that the displayed record sets can vary. Thus I guess that this approach
> (which works together with Python multi-threading functionality) will need
> further software adjustments.
I stumbled on general software development challen
> It is now possible to match the comments before, within, and after the
> match of a token, via a comments metavariable.
Would anybody become interested to discuss corresponding software development
challenges and fine-tuning possibilities any more since the support for
the Python programming lan
Hello,
The metavariables of the semantic patch variables provide a programming
interface for various information from source code.
They were designed in the way so far that a single primary content is handled.
The contents can refer also to more detailed data structures then.
The system default is
>> How do you think about to filter any text by regular expressions
>> for semantic patch language constraints?
>
> Not supported.
This software limitation and current development status has got consequences
as usual.
* It would be nice if comment contents could be directly restricted also by
t
> 2, A general method.
> We also try to get the list of functions to consider by writing a SmPL,
> but this method is not feasible at present, because it is not easy to parse
> the comment
> header information of these functions.
The situation was improved once more also for the Coccinelle softwa
> We currently use the following Ocaml script to automatically
> collect functions that need to be considered.
>
> @initialize:ocaml@
> @@
>
> let relevant_str = "use of_node_put() on it when done"
I suggest to reconsider this search pattern.
The mentioned words are distributed over text lines in
>> Thus I imagine that an other documentation format would be safer
>> and more helpful for the determination of a corresponding API
>> system property.
>
> Our script will remove '* ','\ n','\t' and so on from the comments in the
> function header
> and then merge them into one line,
* Would you
> let add_function f c =
> if not (List.mem f !relevant_functions)
> then
> begin
> let s = String.concat " "
> (
> (List.map String.lowercase_ascii
>(List.filter
> (function x ->
>Str.string_match
>
> Does such a source code analysis approach indicate any details
> which should be improved for the affected software documentation?
I have constructed another SmPL script variant.
It can point out that the text “ when done” occurs in comment lines before
48 function implementations which are pro
> Just wrapping the assignment into the macro call turned out to be easy.
This feedback seems to be promising.
> But I haven't found a way to remove the now #ifdef :(
I get the following test result for a corresponding SmPL transformation
approach.
@replacement@
identifier value;
@@
-#ifdef C
> It seems that spatch currently just doesn't understand preprocessor
> directives at all,
I find this view only partly appropriate.
There is preprocessor functionality supported by the semantic patch language.
Example:
https://github.com/coccinelle/coccinelle/blob/cad4c0705f9e37f501531e133d3a47b
> #ifdefs are comments.
I wonder about this wording.
I hope that the corresponding software situation can be improved further
for complete support of preprocessor functionality.
> If you remove a contiguous sequence of things, the comments between them
> disappear as well.
Such a source code c
> Ifdefs are parsed as comments.
I am curious under which circumstances this software situation
can be changed for the better support of preprocessor functionality.
Regards,
Markus
___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mai
Hello,
I occasionally use the software “SQLAlchemy” for easy storage of source code
data.
I noticed once more that information was not permanently stored
if the parameter “-j 4” was passed to the program “spatch” while
the database “PostgreSQL 11.3-7.1” was selected as the desired storage system.
> but not:
>
> @@
> @@
>
> - #ifdef FOO
> bar();
> - #endif
The deletion of these preprocessor statements is not directly supported
in the shown way by the Coccinelle software at the moment.
But I got another code transformation idea which would not be so convenient.
The semantic patch language
>> Will similar software updates become more challenging for the initially
>> described handling of designated initialisers for known data structures?
>
> This is in the spirit of the solution I already proposed.
How do you think about the following SmPL transformation approach?
@replacement@
con
>> Will similar software updates become more challenging for the initially
>> described handling of designated initialisers for known data structures?
>
> This is in the spirit of the solution I already proposed.
Would you like to compare transformation results also for the following SmPL
change s
> Just wrapping the assignment into the macro call turned out to be easy.
I am curious how your transformation approaches will evolve further.
> But I haven't found a way to remove the now #ifdef :(
The support for preprocessor functionality is limited by the semantic patch
language so far.
Wou
101 - 200 of 1817 matches
Mail list logo
