>> Would you like to achieve any improvements for automatic code beautification?
>> https://github.com/coccinelle/coccinelle/issues/37
>
> If you want to report a problem,
I became curious again if more contributors would become interested
to influence a possibly known software situation a bit
Hello,
The semantic patch language supports also to convert conditional statements
into usages of the ternary operator.
How much can the Coccinelle software help with pretty-printing of generated
source code in this area?
Would you like to achieve any improvements for automatic code
> We tested and found that both <...x...> and <+... x ...+> variants work fine.
Is the difference in the functionality from this SmPL construct clear already?
> We use <... x ...> instead of <+... x ...+> here to eliminate the following
> false positives:
Do we stumble on another software
> We will also provide an example written in Python later.
Will the code move from the commit description into a file
for your next patch version?
> We first use this script to find out all the function names to be processed,
I am still curious on how the output format selection will become
> By the way: do we have any mechanism for explicitly suppressing
> individual warnings (some kind of annotation),
I do not know such an accepted specification interface
(for the handling together with SmPL scripts) so far.
How would you identify possibly unwanted messages in a safe way?
> when
From: Markus Elfring
Date: Mon, 1 Jul 2019 10:00:39 +0200
The function “devm_ioremap_resource” contains appropriate error reporting.
Thus it can be questionable to present another error message
at other places.
Provide design options for the adjustment of affected source code
by the means
> Please actually try things out before declaring them to be useless.
This feedback provides also another opportunity for collateral evolution
in some directions. I am curious on how involved uncertainty can be fixed around
possibly different interpretation for provided software functionality.
+if (x == NULL || ...) S
+... when != e = (T)x
+when != true x == NULL
…
> I assume that it was added because it was found to be useful.
We can get different software development opinions also on
this implementation detail.
> Please actually try things out before declaring
>> +if (x == NULL || ...) S
>> +... when != e = (T)x
>> +when != true x == NULL
>
> I wonder if this code exclusion specification is really required
> after a null pointer was checked before.
I would like to add another view for this implementation detail.
The when constraint can express a
>> +x =
>> +(of_…
>> +|of_…
>> +)@p1(...);
>
> Did you actually test this? I doubt that a position metavariable can be
> put on a ) of a disjunction.
Would you ever like to support this possibility?
>> +|return
>> +(x
>> +|of_fwnode_handle(x)
>> +);
>
> The original code is much more readable.
>> +x =
>> +(of_…
>> +|of_…
>> +)@p1(...);
>
> Did you actually test this? I doubt that a position metavariable can be
> put on a ) of a disjunction.
Would you ever like to support this possibility?
>> +|return
>> +(x
>> +|of_fwnode_handle(x)
>> +);
>
> The original code is much more readable.
> The counter must be decremented after the last usage of a device node.
Thanks for your next try to improve the software situation
also in this area.
> We find these functions by using the following SmPL:
Would it be nicer to use the word “script” also here?
>
> @initialize:ocaml@
> @@
>> Where did the Coccinelle software get the impression that anything
>> would be added too often at the end of such a function implementation?
>
> Without the semantic patch and the C source code,
You have access to data from both files already.
> I can't answer the question.
Is it more
>> replacement: already tagged token:
>
> You try to add two things one one token, which is not allowed.
How do you think about to clarify why a source file adjustment
like the following can let my SmPL script succeed in a test configuration?
elfring@Sonne:~/Projekte/Coccinelle/Probe> diff -u
>>> You can try with the option --debug.
>>> Or if that doesn't help with the option --verbose-ctl-engine.
>>
>> How can these parameters help to clarify undesirable run time
>> characteristics?
>
> How about actually looking at the results yourself?
I did that. - I do not find these extra data
> Maybe there are too many metavariable bindings.
Under which circumstances would such a situation really occur?
How do you think about my SmPL script example for the shown use case?
> You can try with the option --debug.
> Or if that doesn't help with the option --verbose-ctl-engine.
How can
> * The complete source file seems to be very challenging for testing
> the run time characteristics.
How are the chances to clarify the different test results for this source code
transformation approach with the software combination “Coccinelle
1.0.7-00211-geaa13d59-dirty
(OCaml 4.07.1)”?
> @@
> expression x;
> constant c1,c2;
> @@
>
> x = c1;
The SmPL manual contains the promising wording “As metavariables are bound
and inherited across rules, …”.
https://github.com/coccinelle/coccinelle/blob/c6d7554edf7c4654aeae4d33c3f040e300682f23/docs/manual/cocci_syntax.tex#L179
The
> @@
> expression x;
> constant c1,c2;
> @@
>
> x = c1;
> (
> x = c1;
> |
> *x = c2;
> )
Thanks for your suggestion of the possible usage of a SmPL disjunction.
* Does it indicate a search attempt to match the first assignment statement
twice
(for the implementation of exclusion of duplicate
> The expected difference can trigger the need to express this detail
> by the usage of two identifiers based on the same metavariable type.
I guess that this wording should be clarified a bit more according to
the current software development status around the semantic patch language.
A
Hello,
The semantic patch language supports metavariables.
It can occur then that a source code search should be performed for items
which should be different while they belong still to the same data type.
(If these items would be identical, the software situation would provide
opportunities to
Am 23.06.19 um 15:13 schrieb Julia Lawall:
>
>
> On Sun, 23 Jun 2019, Markus Elfring wrote:
>
>>> Try
>>>
>>> ... when any
>>>
>>> just before the final ). In some circumstaces the parser doesn't accept
>>> an expression at the
> Try
>
> ... when any
>
> just before the final ). In some circumstaces the parser doesn't accept
> an expression at the end of a sequence like you have here.
Thanks for your quick response.
The addition of such a SmPL ellipsis helps somehow.
But I am still not pleased with the generated
> Try
>
> ... when any
>
> just before the final ). In some circumstaces the parser doesn't accept
> an expression at the end of a sequence like you have here.
Thanks for your quick response.
The addition of such a SmPL ellipsis helps somehow.
But I am still not pleased with the generated
> Yu can do whatever you want, but you will get lotsof false positives if
> you keep it. If you really want a star on the declaration then you need
> to make two rules. The first that finds the positions of the places that
> match and the second that only puts a * when there is both a matched
>
> Yu can do whatever you want, but you will get lotsof false positives if
> you keep it. If you really want a star on the declaration then you need
> to make two rules. The first that finds the positions of the places that
> match and the second that only puts a * when there is both a matched
>
>>> It could be helpful to replace the last line by:
>>>
>>> (
>>> e3 = <+...var...+>
>>
>> Can this SmPL specification make sense as another when constraint?
>
> No.
I imagine that a few extensions like the following can become safer.
when != do ds while( \( var bo e3 \| var \) );
>>> In that case, it would also be beneficial to remove the *
>>
>> I find the asterisk required here
>
> Yu can do whatever you want, but you will get lotsof false positives if
> you keep it. If you really want a star on the declaration
I would prefer to use a minus character for the
> It could be helpful to replace the last line by:
>
> (
> e3 = <+...var...+>
Can this SmPL specification make sense as another when constraint?
> |
> * var = e3
> )
>
> In that case, it would also be beneficial to remove the *
I find the asterisk required here
> on the variable
>> elfring@Sonne:~/Projekte/Linux/next-patched> spatch
>> ~/Projekte/Coccinelle/janitor/show_questionable_variable_initialisation1.cocci
>> drivers/misc/lkdtm/core.c
>> …
>> exn while in timeout_function
>> Fatal error: exception Coccinelle_modules.Common.Impossible(56)
>>
>>
>> How do you think
Hello,
I have tried out to build the current Coccinelle software again based on
the OPAM switch “4.08.0”.
Unfortunately, I stumble on the following error message.
…
ocamlfind ocamlc -c -no-alias-deps -I . stdcompat__pervasives.ml -o
stdcompat__pervasives.cmo
File "stdcompat__pervasives.ml",
Hello,
I became interested in another source code transformation again.
I would like to move a bit of common code to the end of a function
implementation
with the help of the following script for the semantic patch language.
@replacement@
expression info, result;
identifier target, work;
type
> I still don't see the point of specifying return. Why not just S, where S
> is a statement metavariable?
Do you find the following SmPL change specification more appropriate?
@deletion depends on patch@
expression e;
statement s;
@@
e = devm_ioremap_resource(...);
if (IS_ERR(e))
(
-{
-
> I still don't see the point of specifying return. Why not just S, where S
> is a statement metavariable?
Do you find the following SmPL change specification more appropriate?
@deletion depends on patch@
expression e;
statement s;
@@
e = devm_ioremap_resource(...);
if (IS_ERR(e))
(
-{
-
> I think that something like
>
> if (IS_ERR(e))
> {
> <+...
> *dev_err(...)
> ...+>
> }
>
> would be more appropriate. Whether there is a return or not doesn't
> really matter.
Do you find the following SmPL change specification useful and acceptable?
@deletion depends on patch@
expression e;
>> Would you prefer to clarify a more advanced approach?
>
> I think that something like
>
> if (IS_ERR(e))
> {
> <+...
> *dev_err(...)
> ...+>
> }
>
> would be more appropriate.
This SmPL construct can be more powerful.
> Whether there is a return or not doesn't really matter.
Such an
>> +@display depends on context@
>> +expression e;
>> +@@
>> + e = devm_ioremap_resource(...);
>> + if (IS_ERR(e))
>> + {
>> +* dev_err(...);
>> +return (...);
>> + }
>
> Why do you assume that there is exactly one dev_err and one return after
> the test?
I propose to start with the
>> +@display depends on context@
>> +expression e;
>> +@@
>> + e = devm_ioremap_resource(...);
>> + if (IS_ERR(e))
>> + {
>> +* dev_err(...);
>> +return (...);
>> + }
>
> Why do you assume that there is exactly one dev_err and one return after
> the test?
I propose to start with the
From: Markus Elfring
Date: Thu, 20 Jun 2019 19:12:53 +0200
The function “devm_ioremap_resource” contains appropriate error reporting.
Thus it can be questionable to present another error message
at other places.
Provide design options for the adjustment of affected source code
by the means
Hello,
A patch on a topic like “[next] lkdtm: remove redundant initialization of ret”
caught also my software development attention.
https://lkml.org/lkml/2019/6/14/265
https://lore.kernel.org/patchwork/patch/1088971/
https://lore.kernel.org/lkml/20190614094311.24024-1-colin.k...@canonical.com/
>> Would you like to add this information to the software documentation?
>
> Not really. The documentation can't defend against everyone's imagination.
Will it become helpful to mention the metavariable type “expression *”
also in the SmPL manual?
>> Would you like to add this information to the software documentation?
>
> Not really. The documentation can't defend against everyone's imagination.
Will it become helpful to mention the metavariable type “expression *”
also in the SmPL manual?
> You can't specify pointer dereferences by metavariables.
Thanks for another clarification for a detail by the Coccinelle software.
I assumed that this would be useful functionality for the specification
“expression *X;”.
> The pattern is only in the pattern. It is not partly in the
>>> Metavariables have types. Here X has pointer type.
>>
>> Our understanding of this software detail seems to match.
>>
>> But I assume that the asterisk can be treated in a different way by
>> the isomorphism definition language in comparison to the semantic
>> patch language.
>> How much does
> How would Coccinelle know that a pointer is expected if there is no asterisk?
I am still trying to achieve a better understanding around the interpretation
of the specification “expression *X;”.
> How would Coccinelle know that a pointer is expected if there is no asterisk?
SmPL expression metavariables can handle also pointer variables from C code,
can't they?
Type distinctions have got other consequences for isomorphism definitions.
Regards,
Markus
> Isomorphisms have a cost, so the provided isomorphism only converts !X to
> X == NULL when X is a pointer.
It seems that the Coccinelle software has got restrictions on
the interpretation of pointers so far.
Is a pointer recognised for application of isomorphisms by
the semantic patch language
>> Would you like to check the software circumstances once more
>> for the generation of a similar code structure by a C compiler
>> (or optimiser)?
>
> As said: unfortunately, I don't have the time to do that
I became curious if you would like to adjust your software development
attention a bit
> If you turn off isomorphisms, it will only match exactly what you have
> written.
This setting can occasionally be appropriate.
> Isomorphisms have a cost, so the provided isomorphism only converts !X to
> X == NULL when X is a pointer. If you want to make an isomorphism that
> does
> As I already told you, the isomorphisms are applied before matching
> against the C code. At that time, this information is not available.
Can the software situation be clarified also by omitting Coccinelle's
isomorphisms?
(Can this functionality be temporarily switched off for a specific
>> Two function calls were combined in this function implementation.
>> Inline corresponding code so that extra error checks can be avoided here.
>
> What exactly is the purpose of this ?
I suggest to take another look at the need and relevance of involved
error checks in the discussed function
>> Example:
>> struct setkey_parm *psetkeyparm;
>
> As I already told you, the isomorphisms are applied before matching
> against the C code. At that time, this information is not available.
Under which circumstances will the Coccinelle software become able
to take available data type
>> Can the mentioned SmPL script variant work also without taking extra
>> software transformations by isomorphism specifications into account?
>
> Well, you already know that it doesn't. So oviously the answe is that it
> cannot.
At the moment.
> If you indicate that the expression ex is a
> Isomorphisms happen in advance, not during the matching process.
Can the mentioned SmPL script variant work also without taking extra
software transformations by isomorphism specifications into account?
Regards,
Markus
___
Cocci mailing list
>> Should an isomorphism specification like “not_ptr2” help here?
>> https://github.com/coccinelle/coccinelle/blob/19ee1697bf152d37a78a20cefe148775bf4b0e0d/standard.iso#L157
>
> No, because Coccinelle does not know that it is a pointer.
> How should it know?
Can the software determine that the
> In the second case, Coccinelle has no way of knowing that ex is a pointer,
Can the software support pointer expressions better?
> so it doesn't feel motivated to consider that ex should be compared to NULL.
Should an isomorphism specification like “not_ptr2” help here?
Hello,
A patch on a topic like “staging/rtl8723bs/core/rtw_ap: Remove redundant call
to memset” caught also my software development attention.
https://lkml.org/lkml/2019/6/15/220
https://lore.kernel.org/patchwork/patch/1089416/
>> Two function calls were combined in this function implementation.
>> Inline corresponding code so that extra error checks can be avoided here.
>
> I don't see any point to this at all.
Would you like to take another look at corresponding design options?
How do you think about to check run
From: Markus Elfring
Date: Fri, 14 Jun 2019 11:05:33 +0200
Two function calls were combined in this function implementation.
Inline corresponding code so that extra error checks can be avoided here.
Signed-off-by: Markus Elfring
---
drivers/base/platform.c | 39
> Apparently I'm missing this obscure line in the documentation:
>
> "Fresh identifier metavariables must only be used in + code."
>
> Any suggestions on how to work around this, other than use Python?
Would you get into the mood to adjust this software situation any more?
(Increase OCaml
>> The flag “IORESOURCE_MEM” is passed as the second parameter for the call
>> of the function “platform_get_resource” in this refactoring.
>
> In that particular case, we maybe should consider separate inline
> helpers instead of passing this is a parameter.
>
> Maybe it would even be more
Am 10.06.19 um 23:00 schrieb Julia Lawall:
>
>
> On Sun, 9 Jun 2019, Markus Elfring wrote:
>
>> Hello,
>>
>> The Coccinelle software supports also a variant of parallel data processing
>> after the parameter “--jobs” was passed.
>> htt
> https://github.com/coccinelle/coccinelle/issues/50
Would you like to adjust the situation around better software collaboration?
https://docs.sqlalchemy.org/en/13/core/pooling.html#using-connection-pools-with-multiprocessing
Regards,
Markus
___
Cocci
Hello,
The Coccinelle software supports also a variant of parallel data processing
after the parameter “--jobs” was passed.
https://github.com/coccinelle/coccinelle/blob/7ec31ed1fadf738bc487ccefdc63bfe0598f44cc/docs/manual/spatch_options.tex#L745
It is nice when it works to distribute analysis
>>> +- e1 = devm_ioremap_resource(arg4, id);
>>> ++ e1 = devm_platform_ioremap_resource(arg1, arg3);
>>
>> Can the following specification variant matter for the shown SmPL
>> change approach?
>>
>> + e1 =
>> +- devm_ioremap_resource(arg4, id
>> ++ devm_platform_ioremap_resource(arg1, arg3
> +- e1 = devm_ioremap_resource(arg4, id);
> ++ e1 = devm_platform_ioremap_resource(arg1, arg3);
Can the following specification variant matter for the shown SmPL
change approach?
+ e1 =
+- devm_ioremap_resource(arg4, id
++ devm_platform_ioremap_resource(arg1, arg3
+
> Would you like to try another SmPL script variant out?
@replacement@
constant text;
expression value;
@@
.driver = {
- .name = text,
- .of_match_table = value,
- },
+ .name = text,
+ .of_match_table = of_match_ptr(value),
+ },
How do you
> 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.
>> 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
>> 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@
> 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
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
> 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
> #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
> 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:
> 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
> 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
> 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
>
>> 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
> 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
> 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
>> 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
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
> 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
> 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
> … 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 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
>> @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.
>
> 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
> 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
>> @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
> 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
> 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
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
> 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
> 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();\@c4\)” into another SmPL rule?
Can it make sense to split the OCaml script rule then
> 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
>> * 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 “...
>> 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
>> 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
601 - 700 of 1468 matches
Mail list logo
