Re: [Cocci] Replacing a std::string check by strcmp() with SmPL

> The strcmp output has to be compared to zero strcmp(src_name, > "equalizer_input_level") == 0. Would you like to let the following script for the semantic patch language perform any changes in your source files automatically? @replacement@ constant c; identifier text; statement is, es; @@

Re: [Cocci] Searching for usage of “auto” with SmPL?

>> meta: parse error: >> File "show_variable_definition_with_auto3.cocci", line 4, column 8, >> charpos = 46 >> around = 'auto', >> whole content = typedef auto; > > I understood already that it was not meant as a type. I tried your suggestion out if the idea can work finally. May such a

Re: [Cocci] Searching for usage of “auto” with SmPL?

>> >> https://github.com/wwmm/pulseeffects/blob/acb5161a6ab8d3b0c395ed2809d3318ccf4931bc/src/source_output_effects.cpp#L6 > > I guess it would be fine if you put > > typedef auto; > > among the metavariables? I would like to show another software test result. @display@ expression E;

Re: [Cocci] Replacing usages of “auto” with SmPL?

> You're not actually showing a need. I disagree. - Our needs are just different. > Ie you don't have a real piece of software in which this transformation is > actually needed. Under which circumstances will the clarification of related components become more attractive? Regards, Markus

Re: [Cocci] Replacing usages of “auto” with SmPL?

>> @replacement@ >> @@ >> -auto >> +my_type > > There is nothing to support this. Thanks for such feedback. > So far I don't have the impression that anyone has had a need for it either. How often will I be the first one who shows a need for further software extensions? Would anybody like

Re: [Cocci] Replacing usages of “auto” with SmPL?

> I think it expects a type as well. I don't know if that is a reasonable > assumption in C or in C++. Can a source code transformation approach like the following make sense? @replacement@ @@ -auto +my_type elfring@Sonne:~/Projekte/Coccinelle/Probe> spatch --parse-cocci replace_auto1.cocci

Re: [Cocci] Replacing a std::string check by strcmp() with SmPL

>> @display@ >> expression X; >> identifier I; >> @@ >> *auto I = X(...); … > I think it expects a type as well. I don't know if that is a reasonable > assumption in C or in C++. How do you think about to interpret such a variable definition in the way that the omission of an other data type

Re: [Cocci] Replacing a std::string check by strcmp() with SmPL

> If you are showing a patch, then the first column is empty, > except for the - and + characters. You are right. I am sorry for my misinterpretation of the “indentation” at this place. Regards, Markus ___ Cocci mailing list Cocci@systeme.lip6.fr

Re: [Cocci] Replacing a std::string check by strcmp() with SmPL

>> Do you distinguish between the storage class specifier >> and other uses of such a key word? >> https://en.cppreference.com/w/cpp/language/auto > > Sorry. I know nothing about C++. I guess that you know something also for this programming language according to the program option “--c++”.

Re: [Cocci] Replacing a std::string check by strcmp() with SmPL

> Where is the space that yoyu are concerned about? … @@ -1,7 +1,7 @@ void on_message_element … ↑ How was this character added at the first column in this line of my software test approach? >> >>

[Cocci] Replacing a std::string check by strcmp() with SmPL

Hello, I have tried the following small script variant out for the semantic patch language. @replacement@ constant c; identifier text; expression x; statement is, es; @@ char* text = x(...); if ( + strcmp( text + , - == std::string( c ) ) is else es A corresponding

Re: [Cocci] [PATCH v2 3/3] tests: Add test case for bool

> …, followed by ret on > the next to next line. Would you like to improve this wording? Regards, Markus ___ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] [PATCH v2 2/3] parsing_hacks: Add bool to list of known typedefs

> Before: > passed:bool I wonder if subsequent duplicate information can really help to achieve a better understanding by the suggested description of a software situation. Regards, Markus ___ Cocci mailing list Cocci@systeme.lip6.fr

Re: [Cocci] [PATCH v2 0/3] cocci: Improve management of macros before typedefs

> If is a known typedef (such as u8 or *_t) then label > as a CppMacro. Subsequent cases will label correctly as a > typedef ident. > > Also add bool to the list of known typedefs so that cases of Can a wording like the following be nicer for such a change description? Label as a CppMacro

Re: [Cocci] [PATCH] parsing_c: Handle case of macro before typedef

> A case in parsing_hacks.ml sometimes mislabels as a > typedef ident. Can a wording like “as a type definition identifier” be nicer for this description of a software situation? Regards, Markus ___ Cocci mailing list Cocci@systeme.lip6.fr

Re: [Cocci] [PATCH 2/2] tests: Add test case for * const *

… > +++ b/tests/ptrconstptr.res > @@ -0,0 +1,3 @@ > +void main() { > + const char *const *y; > +} According to which coding style should such a test result be interpreted? Regards, Markus ___ Cocci mailing list Cocci@systeme.lip6.fr

Re: [Cocci] parsing_c: Add space for tokens after *

>> https://github.com/coccinelle/coccinelle/issues/37 > > Not sure what you mean. I suggest to take another look also at the circumstances for the placement of white-space characters (around asterisks). I guess that we come along different pretty-printing preferences. Regards, Markus

Re: [Cocci] [PATCH] parsing_c: Add space for tokens after *

> In certain cases, there is no space added after the Pointer type. Will such a pretty-printing detail matter also for the clarification of a topic like “Make change influence configurable for coding style rules”? https://github.com/coccinelle/coccinelle/issues/37 Regards, Markus

Re: [Cocci] [PATCH v3] coccinelle: semantic patch to check for inappropriate do_div() calls

> This semantic patch is inspired by Mateusz Guzik's patch: Does such a wording mean also that you would like to support the operation mode “patch” by this SmPL script? Regards, Markus ___ Cocci mailing list Cocci@systeme.lip6.fr

Re: [Cocci] [2/2] tests: Add test case for user comments attached to identifiers

> +@ script:python r1 @ > +id; > +@@ > +coccinelle.id = "id/* user comment */" I am still looking for further clarification around this programming interface. See also topics like the following: * Propagating values back from Python script to SmPL rule with other metavariable type than

Re: [Cocci] [v3] coccinelle: semantic patch to check for inappropriate do_div() calls

>> Can the avoidance of duplicate source code (according to SmPL disjunctions) >> trigger positive effects on run time characteristics and software >> maintenance? > > Markus. Please stop asking this question. This will not happen for a while. > You are bothering people with this advice, I

Re: [Cocci] [v3] coccinelle: semantic patch to check for inappropriate do_div() calls

>> * I suggest once more to adjust the dependency specifications for the usage >>   of these functions by SmPL rules. > > Most of the functions here are for all operation modes. I got an other understanding for this software. You added the information “also filter out safe consts for context

Re: [Cocci] [PATCH 2/2] tests: Add test case for user comments attached to identifiers

> Add a test case for both of the erroneous cases. Thanks for your contribution. Will a slightly different subject be more appropriate for this patch? > +@ r0 @ > +type t; > +position p; I suggest to omit this variable for the shown simple SmPL script. > +@ script:python r1 @ > +id; > +@@ >

Re: [Cocci] [PATCH v3] coccinelle: semantic patch to check for inappropriate do_div() calls

> +@initialize:python@ … > +def filter_out_safe_constants(str): … > +def construct_warnings(str, suggested_fun): * I suggest once more to adjust the dependency specifications for the usage of these functions by SmPL rules. * Can the local variable “msg” be omitted? >

Re: [Cocci] [v2] coccinelle: semantic code search for inappropriate do_div() calls

> The code is fine as it is in these respects. I have noticed additional software development opportunities. Thus I became curious if further collateral evolution will happen. Regards, Markus ___ Cocci mailing list Cocci@systeme.lip6.fr

Re: [Cocci] [PATCH v2] coccinelle: semantic patch to check for inappropriate do_div() calls

> +@initialize:python@ … > +def construct_warnings(str, suggested_fun): This function will be used only for the operation modes “org” and “report”. Thus I suggest to replace the specification “initialize” by a corresponding dependency which is already applied for the SmPL rule “r”. Can

Re: [Cocci] [v2] coccinelle: semantic patch to check for inappropriate do_div() calls

>> Does the dependency management around the application of SmPL disjunctions >> need any further clarification? > > I already clarified it. The python code will only be executed if the > variables that it references have values. The criterion is not just > whether the rule r was matched.

Re: [Cocci] [v2] coccinelle: semantic patch to check for inappropriate do_div() calls

>> Does the Coccinelle software ensure that a variable like “r.ul” contains >> really useful data even if the expected branch of the SmPL disjunction >> was occasionally not matched? > > The python code will only be executed if it does. The Python scripts will be executed if the SmPL rule “r”

Re: [Cocci] [v2] coccinelle: semantic patch to check for inappropriate do_div() calls

>> Thus I suggest now to split the source code search pattern into >> four separate rules. > > Why? Does the Coccinelle software ensure that a variable like “r.ul” contains really useful data even if the expected branch of the SmPL disjunction was occasionally not matched? Regards, Markus

Re: [Cocci] [PATCH v2] coccinelle: semantic patch to check for inappropriate do_div() calls

> - fix 'WARNING:' twice in each case. A duplicate text was removed. > +@script:python depends on org@ > +p << r.p; > +ul << r.ul; I interpret this variable assignment in the way that it will work only if the corresponding branch of the SmPL disjunction was actually matched by the referenced

Re: [Cocci] Adding semicolons after macro calls

> The only short term suggestion I have is the following: I wonder about the specification of two statement variables here. Under which circumstances can a transformation approach (like the following) work as desired? @addition@ identifier action; statement s; @@ <+... action(...) +; s

Re: [Cocci] transforming arguments to statement macros?

> It uses a regular expression to detect that a statement starts with the > word ASSERT, and matches the next statement as well, and then in another > rule adds a ; before the subsequent statement. Can related improvements for the supported programming interfaces help to split the available

Re: [Cocci] coccinelle: semantic patch to check for inappropriate do_div() calls

>>> +( >>> +* do_div(f, l); >>> +| >>> +* do_div(f, ul); >>> +| >>> +* do_div(f, ul64); >>> +| >>> +* do_div(f, sl64); >>> +) >> >> I suggest to avoid the specification of duplicate SmPL code. >> >> +@@ >> +*do_div(f, \( l \| ul \| ul64 \| sl64 \) ); > > I don't se any point to this. Can such

Re: [Cocci] [PATCH] coccinelle: semantic patch to check for inappropriate do_div() calls

> +virtual context > +virtual org > +virtual report The operation mode “patch” is not supported here. Should the term “semantic code search” be used instead in the subject again? > +@@ > +( > +* do_div(f, l); > +| > +* do_div(f, ul); > +| > +* do_div(f, ul64); > +| > +* do_div(f, sl64); > +) I

Re: [Cocci] transforming arguments to statement macros?

> I would prefer that the macros were written with the do-while pattern, > but it's a legacy codebase that uses HGOTO_ERROR() no fewer than 12,000 > times, and most occurrences have no semicolon. I will have to automate > the conversion, and I guess that I cannot use spatch to do it. Would you

[Cocci] Experiences around program transformations (including Java)

Hello, I have taken another look also at contents from the document “Semantic Patches for Java Program Transformation (Experience Report)”. https://drops.dagstuhl.de/opus/volltexte/2019/10814/ https://dx.doi.org/10.4230/LIPIcs.ECOOP.2019.22 My software development attention grew then for a few

Re: [Cocci] Changing format string usage with SmPL?

> After some research, I could create a Python function called > fmt_replace_by_pos() to replace the %fmt by the Indice position. I imagine that this development direction can become more interesting. Now I would like to point a few implementation details out which can be improved in the shown

Re: [Cocci] Changing format string usage with SmPL?

> Therefore, I could find the %fmt and replace by whatever I want based on > the *expression-list. *currently struggled on that. Are you also looking for direct support of such expression lists by Coccinelle's programming interface (see also “man coccilib”)? Regards, Markus

Re: [Cocci] Changing format string usage with SmPL?

> Unfortunately, it doesn't work. A bit more information would be nice for the explanation of the failure reason. I assume that you are still looking for better support of format strings with several conversion parameters. > But, I am working on some solutions using Python. I am curious how

Re: [Cocci] Generation of expression lists by SmPL script rules?

> OK, if you may have more than one argument to your print, > then you can find the offset using an expression list metavariable: How challenging would it be to add support for the construction of such expression lists by programming interfaces (besides “make_expr”) of Coccinelle's software

Re: [Cocci] Changing format string usage with SmPL?

> OK, if you may have more than one argument to your print, > then you can find the offset using an expression list metavariable: > > @r@ > expression list[n] between; > @@ > > print(s,between,h2->name,...) > > Then you can use r.n in your python rule to figure out where is the %s to > change.

Re: [Cocci] Changing format string usage with SmPL?

> > Which algorithm will become sufficient for your data processing needs > > around the usage of functions with variadic arguments because of format > > strings? > > Actually, I really didn't get why you're asking about that. I suggest to take another look at affected software aspects. >

Re: [Cocci] Changing format string usage with SmPL?

> Basically, I intend to replace alls "%s" called with "mydata->name" by "%m" > with "mydata" or "" How far would you get the desired source code transformation based on software extensions around a search pattern like the following? @find@ expression action; expression list context, inputs;

Re: [Cocci] Replacing printf() parameters according to used data types

> Maybe this will help you: > > @r@ > format list d; > @@ > > "%@d@" > > @script:ocaml s@ > d << r.d; > res; > @@ > res := make_expr ("\""^(String.concat "%s" (Str.split_delim > (Str.regexp_string "%d") d))^"\"") Such a replacement approach might look promising. But I got the impression that

Re: [Cocci] Replacing printf() parameters according to used data types

> I am not sure if Coccinelle is able to filter the %fmt e.g: %s only called > with > a parameter of specific data-type. I would expect general support for such a task by the semantic patch language. > Basically, I intend to replace alls "%s" called with "mydata->name" by "%m" > with "mydata"

Re: [Cocci] Replacing printf() parameters according to used data types

> I suggest to take another look at presented implementation details. > > I did it, Such a try is generally nice. > even digging the grammar and ALL samples and didn't find anything similar > to handle format strings with multiple parameters as mentioned. Can this view trigger

Re: [Cocci] Replacing printf() parameters according to used data types

> At the moment, there seems to be a bug. I will check on that. I am also curious how the support will evolve further around advanced data processing for format strings with the semantic patch language. Can another transformation approach become interesting for a corresponding clarification?

Re: [Cocci] Replacing printf() parameters according to used data types

>>. Did you try out to work with SmPL ellipses and disjunctions for this >>purpose?  >   > I didn't it, do you have any suggestions or sample that is it possible > to solve my problem? something to based on. Can you get further development ideas from a transformation approach like the following?

Re: [Cocci] Replacing printf() parameters according to used data types

> For now, I just would like to detect and patch the mentioned example. Did you try out to work with SmPL ellipses and disjunctions for this purpose? > I could imagine that could be possible do using Python,. The application of the semantic patch language (Coccinelle software) should be safer

Re: [Cocci] Replacing printf() parameters according to used data types

> @r1_stack@ > struct mydata SMD; > format F =~ "s"; > @@ > -my_printf("%@F@", SMD.name); > +my_printf("%m", ); > $ > > But, I can match only with partial content as can be seen below. I find this information for “partial content” unclear at the moment. * Would you like to transform any more

Re: [Cocci] [PATCH 1/2] engine: remove circular references in MINUS/NOREPLACEMENT case

Thanks for your patch. > The cocci info tag can sometimes have circular references in the > MINUS/NOREPLACEMENT case in the transformation. Can it make sense to clarify this software situation a bit more? > Pass the binding info through clean_env to remove circular references. Can such an

Re: [Cocci] Specifying conditional compilation with SmPL

> Coccinelle doesn't currently support adding ifdefs on expressions, > only on statements. Can the following transformation approach ever work @adjustment2@ expression x; @@ +#ifdef USE_F f +#else +g +#endif (x); in addition to this code variant for the semantic patch language? @adjustment1@

Re: [Cocci] Checking influence of variability with SmPL

> An expression metavariable matches an expression of any type. Thanks for such an acknowledgement. * Can this fact trigger corresponding challenges for safe transformations by the semantic patch language? * Would you occasionally like to determine the corresponding data type then? > A

Re: [Cocci] Checking influence of variability with SmPL

Hello, Metavariables of the semantic patch language provide common information. 1. A fixed type (or kind) 2. An entity which can be variable. These properties can be distinguished further. Another example: char c; Such SmPL code looks like the specification of a fixed data type selection for

Re: [Cocci] Concerns around type safety for usage of expressions

> T *ptr for example. 1. Does this information for a “type constraint” distract from my questions? 2. Can the data type become restricted not only by the detail that it refers to a pointer? 3. Why should such a SmPL specification matter for the handling of expressions? Regards, Markus

Re: [Cocci] Concerns around type safety for usage of expressions

Another example: “[PATCH] coccinelle: improve array.cocci” from 2019-11-18 https://public-inbox.org/git/0d9cf772-268d-bd00-1cbb-0bbbec9df...@web.de/ >>> >>> OK, so you already know how to express type constraints for things. >> >> Where do you see that I did this? > > T *ptr for

Re: [Cocci] Concerns around type safety for usage of expressions

>> Another example: >> “[PATCH] coccinelle: improve array.cocci” from 2019-11-18 >> https://public-inbox.org/git/0d9cf772-268d-bd00-1cbb-0bbbec9df...@web.de/ > > OK, so you already know how to express type constraints for things. Where do you see that I did this? > So what are you actually

Re: [Cocci] Concerns around type safety for usage of expressions

>> Do you find it easier to clarify transformation possibilities around >> applications of a macro like “COPY_ARRAY”? >> https://github.com/git/git/blob/d966095db01190a2196e31195ea6fa0c722aa732/git-compat-util.h#L889 > > I still don't understand what you are asking. I hope that also this

Re: [Cocci] Concerns around type safety for usage of expressions

>>> You can specify the type of an expression rather than just expression. >> >> How is this approach different from the search for “specific data types” >> (which I know already)? > > I have no idea what you are referring to. Do you find it easier to clarify transformation possibilities around

Re: [Cocci] Concerns around type safety for usage of expressions

> You can specify the type of an expression rather than just expression. How is this approach different from the search for “specific data types” (which I know already)? I came along an use case where a generic source code search can find update candidates. But it would be nice if safety

[Cocci] Concerns around type safety for usage of expressions

Hello, The semantic patch language supports source code searches also for uses of specific data types. Such restricted searches can occasionally be nice. But we would like to find more software variations often enough. The consequence is that metavariables of the kind “expression” will usually be

Re: [Cocci] Merging SmPL rules

> Is there a simple way how to merge these these rules together? The answer will depend on your expectations for simplicity. > It seems like it should be possible, * Can you identify useful merge criteria already? * Are you aware of software design possibilities from the application of SmPL

Re: [Cocci] field access scoping / check who accesses certain struct members ?

> If you want to check on many types and fields, you can use the following rule: > > @@ > identifier virtual.ty; > struct ty x; > identifier virtual.fld; > @@ > > * x.fld > > Then you can run it with the command-line options: > > -D ty=type_of_interest -D fld=field_of_interest This data

Re: [Cocci] [PATCH 1/4 v2] coccinelle: platform_get_irq: simplify context case

> if ( \( ret < 0 \| ret <= 0 \) ) Can it make sense to specify the comparison by a constraint for a metavariable of the type “binary operator” instead of a SmPL disjunction? Regards, Markus ___ Cocci mailing list Cocci@systeme.lip6.fr

Re: [Cocci] [2/4] coccinelle: platform_get_irq: handle 2-statement branches

> Sorry, I seem to have done something quite wrong on this patch. Interesting … > I will fix it. Thanks. Development will be continued: https://lkml.org/lkml/2019/11/19/1681 https://lore.kernel.org/patchwork/patch/1156089/

Re: [Cocci] [PATCH 2/4] coccinelle: platform_get_irq: handle 2-statement branches

> From: Masahiro Yamada I wonder about this information. Would you like to use the tag “Suggested-by” instead? … > +++ b/scripts/coccinelle/api/platform_get_irq.cocci > @@ -31,6 +31,25 @@ if ( \( ret < 0 \| ret <= 0 \) ) … > +ret = > +( > +platform_get_irq > +| > +platform_get_irq_byname >

Re: [Cocci] [PATCH 2/4] coccinelle: platform_get_irq: handle 2-statement branches

> From: Masahiro Yamada I wonder about this information. Would you like to use the tag “Suggested-by” instead? … > +++ b/scripts/coccinelle/api/platform_get_irq.cocci > @@ -31,6 +31,25 @@ if ( \( ret < 0 \| ret <= 0 \) ) … > +ret = > +( > +platform_get_irq > +| > +platform_get_irq_byname >

[Cocci] Improve parsing for “sha1dc/sha1.c”

Hello, I have tried the following command out with the software combination “Coccinelle 1.0.8-4-g842075f7”. elfring@Sonne:~/Projekte/git/lokal> spatch --parse-c sha1dc/sha1.c … bad: #ifdef DOSTORESTATE5 TYPEDEF:_handle_typedef=false. Not normal if don't come from exn ERROR-RECOV: found sync

[Cocci] Data processing with pointer types/expressions

Hello, I am fiddling with another SmPL script for a while. https://github.com/git/git/blob/177fbab747da4f58cb2a8ce010b3515c86dd67c9/contrib/coccinelle/array.cocci My software development attention increased then also for the used metavariable declarations like the following. * T *src_ptr * T[]

[Cocci] Relationships between kinds of metavariables?

Hello, The semantic patch language supports metavariables. Now I would like to know a bit more about possible relationships between them. Examples: * type * expression Is any kind of metavariable available which would be a superset according to another item? Can the specification of SmPL

Re: [Cocci] Checking size determinations with SmPL

>> *\( sizeof(t) \| sizeof(*e) \) >> >> >> Would it be nice if another script variant can work together with >> such a SmPL disjunction also in this way? > > No. They are quite different because the () is required on a type but > optional on an expression. … >> @display2@ >> expression* e; >>

[Cocci] Checking size determinations with SmPL

Hello, The following code example gets accepted by the Coccinelle software. @display1@ expression* e; type t; @@ *\( sizeof(t) \| sizeof(*e) \) Would it be nice if another script variant can work together with such a SmPL disjunction also in this way? @display2@ expression* e; type t; @@

Re: [Cocci] git-coccinelle: adjustments for array.cocci?

>> + memcpy( >> +( ptr, E, n * >> +- sizeof(*(ptr)) >> ++ sizeof(T) >> +| arr, E, n * >> +- sizeof(*(arr)) >> ++ sizeof(T) >> +| E, ptr, n * >> +- sizeof(*(ptr)) >> ++ sizeof(T) >> +| E, arr, n * >> +- sizeof(*(arr)) >> ++

Re: [Cocci] git-coccinelle: adjustments for array.cocci?

> It can determine the type of t->entries if it has access to the definition > of the type of t. I would like to point another implementation detail out. Another known function was also an update candidate. https://github.com/git/git/blob/9a1180fc304ad9831641e5788e9c8d3dfc10ccdd/pretty.c#L90

Re: [Cocci] git-coccinelle: adjustments for array.cocci?

>> https://github.com/git/git/blob/3edfcc65fdfc708c1c8f1d314885eecf9beb9b67/fast-import.c#L640 >> >> I got the impression that the Coccinelle software is occasionally able >> to determine from the search specification “sizeof(T)” the corresponding >> data type for code like “*(t->entries)”. > > It

Re: [Cocci] git-coccinelle: adjustments for array.cocci?

> --- array-released.diff 2019-11-14 21:29:11.020576916 +0100 > +++ array-reduced1.diff 2019-11-14 21:45:58.931956527 +0100 > @@ -6,24 +6,10 @@ > r->entry_count = t->entry_count; > r->delta_depth = t->delta_depth; > -

Re: [Cocci] git-coccinelle: adjustments for array.cocci?

> --- array-released.diff 2019-11-14 21:29:11.020576916 +0100 > +++ array-reduced1.diff 2019-11-14 21:45:58.931956527 +0100 > @@ -6,24 +6,10 @@ > r->entry_count = t->entry_count; > r->delta_depth = t->delta_depth; > -

Re: [Cocci] git-coccinelle: adjustments for array.cocci?

> Anyway, someone who can reproduce the issue using the latest release > of Coccinelle would be in a better position to file a bug report. Hello, I repeated the discussed source code transformation approach together with the software combination “Coccinelle 1.0.8-4-g842075f7” (OCaml 4.09).

Re: [Cocci] Using a metavariable type for function calls?

>> @@ >> my_function get_content; >> @@ >> -old_stuff >> +get_content This can be another questionable idea around software extensions for the functions “make_…” by the module “Coccilib”. Regards, Markus ___ Cocci mailing list Cocci@systeme.lip6.fr

Re: [Cocci] Using the same replacement for different source code

>> @replacement@ >> binary operator bo = { +, * }; >> expression x, y; >> @@ >> +compute( >> x >> -bo >> +, >> y >> + ) > > I can't figure out what this is an example of? It shows just a possible transformation specification where a SmPL constraint is

Re: [Cocci] Using a metavariable type for function calls?

>> Some metavariable types are supported by the semantic patch language so far. >> Can it become helpful to let a customised function determine the concrete >> value which should be used for a source code transformation specification? > > I have no idea what you are asking for. @@ my_function

[Cocci] Using a metavariable type for function calls?

Hello, Some metavariable types are supported by the semantic patch language so far. Can it become helpful to let a customised function determine the concrete value which should be used for a source code transformation specification? Regards, Markus ___

Re: [Cocci] Checking data processing for parentheses in SmPL scripts

> What is the question, exactly? I became curious to clarify consequences around the error message “unexpected close parenthesis in line 6” for the other SmPL code variant from yesterday. Is the Coccinelle software looking for pairs of parentheses? Regards, Markus

[Cocci] Using the same replacement for different source code

Hello, The following change specification gets accepted by the Coccinelle software. @replacement@ expression x, y; @@ ( -x + y +compute(x, y) | -x * y +compute(x, y) ) I would appreciate if the specification of duplicate SmPL code can be avoided also for such an use case. Thus I have tried

[Cocci] Using the same replacement for different source code

Hello, The following change specification gets accepted by the Coccinelle software. @replacement@ expression x, y; @@ ( -x + y +compute(x, y) | -x * y +compute(x, y) ) I would appreciate if the specification of duplicate SmPL code can be avoided also for such an use case. Thus I have tried

Re: [Cocci] Checking data processing for parentheses in SmPL scripts

> Unfortunately, the error message “unexpected close parenthesis in line 6” > is reported then. The following change specification gets accepted by the Coccinelle software. @adjustment@ expression X; @@ +powerof2 ( -(X-1)& X) - == 0 Would you like to discuss similar SmPL code variations any

Re: [Cocci] [v7] coccicheck: Support search for SmPL scripts within selected directory hierarchy

> Changes in v7: > 1:adjust coccinelle.rst documentation Thanks for your contribution. Now I am curious if other contributors will add corresponding review comments. > 2:fix a repo of "default" I find the word “repo” partly unclear at the moment. Regards, Markus

[Cocci] Checking data processing for parentheses in SmPL scripts

Hello, The following change specification gets accepted by the Coccinelle software. @@ expression X; @@ -((X-1)) == 0 +powerof2(X) See also: https://github.com/DragonFlyBSD/DragonFlyBSD/blob/722c3b8b6376deab9407ff00b5e63018ab3aef0b/test/cocci/useful_macros.cocci#L53 I got into the

[Cocci] RDMA/hns: Checking two kfree() calls in hns_roce_v1_release_lp_qp()

Hello, A coccicheck run provided information like the following. ./drivers/infiniband/hw/hns/hns_roce_hw_v1.c:901:1-6: ERROR: invalid free of structure field ./drivers/infiniband/hw/hns/hns_roce_hw_v1.c:903:1-6: ERROR: invalid free of structure field Generated by:

Re: [Cocci] Fixing SmPL scripts for data output according to structured file formats

> make coccicheck uses --no-show-diff at the approrpiate place so that the * > have no effect if the context option is not chosen. Thanks for your reminder on this command option. How do you think about to look at possibilities around the redirection of output to files so that diff hunks from

[Cocci] Fixing SmPL scripts for data output according to structured file formats

Hello, I have taken another look at a script for the semantic patch language. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/scripts/coccinelle/free/iounmap.cocci?id=cd0207a7bfd29016a4eeb0b0203fa900b41e4eee It belongs to the category of SmPL scripts which support data

[Cocci] Checking data processing for clk_put.cocci

Hello, I would like to clarify the following source code analysis result which can be provided by the tool “coccicheck”. ./drivers/bus/ti-sysc.c:1776:2-8: ERROR: missing clk_put; clk_get on line 1767 and execution via conditional on line 1775 ./drivers/tty/serial/bcm63xx_uart.c:851:2-8: ERROR:

[Cocci] Checking data processing around invalidate_aliases()

Hello, I would like to clarify the following source code analysis result. elfring@Sonne:~/Projekte/Linux/next-patched> spatch -D report scripts/coccinelle/api/d_find_alias.cocci fs/ceph/caps.c … fs/ceph/caps.c:3051:9-11: Missing call to dput() at line 3063. I have got the impression that a

Re: [Cocci] [PATCH v6] coccicheck: Support search for SmPL scripts within selected directory hierarchy

> *Allow defining the environment variable “COCCI” as a directory to > search SmPL scripts. > > *Start a corresponding file determination if it contains an acceptable > path. > > *Update coccinelle.rst documents for use coccicheck with a directory > selection ‣ Do you really insist to use an

Re: [Cocci] Coccinelle: zalloc-simple: Checking data processing for a bigger SmPL disjunction

>> But I would like to add the last case distinction also to a similar >> disjunction in the known (and discussed) SmPL script version. > > What is "the known (and discussed) SmPL script version"? I am preparing further software updates. Fixes: dfd32cad146e3624970eee9329e99d2c6ef751b3

[Cocci] Coccinelle: zalloc-simple: Checking data processing for a bigger SmPL disjunction

Hello, I have tried the following small script variant out for the semantic patch language. @adjustment@ type T, T2; expression x,E1,E2,E3,E4; statement S; @@ ( - x = kmalloc(E1,E2); + x = kzalloc(E1,E2); | x = (T)dma_alloc_coherent(E2,E1,E3,E4); ) if ((x==NULL) || ...) S -

Re: [Cocci] Coccinelle: zalloc-simple: Adjust a message construction

>> * Simplify a message construction in a Python script rule >> for the semantic patch language. > > The benefit is what? The avoidance to store the shown string in the extra Python variable “msg”. >> * Delete also a duplicate space character then. I find the proposed wording a bit nicer,

[Cocci] [PATCH] Coccinelle: zalloc-simple: Adjust a message construction

From: Markus Elfring Date: Sun, 3 Nov 2019 20:00:30 +0100 * Simplify a message construction in a Python script rule for the semantic patch language. * Delete also a duplicate space character then. Fixes: dfd32cad146e3624970eee9329e99d2c6ef751b3 ("dma-mapping: remove dma_zalloc_coh

Re: [Cocci] Checking code layout for adding jump targets with SmPL

> I guess that another small test approach will trigger further development > considerations. @replacement@ @@ if (...) -{ +info: +puts("surprise"); -} … elfring@Sonne:~/Projekte/Coccinelle/Probe> spatch empty_compound_statement_for_if1.c replace_empty_compound_statement_for_if5.cocci … @@

Re: [Cocci] Checking code layout for adding jump targets with SmPL

> How would you like to improve the pretty-printing for the Coccinelle software? I guess that another small test approach will trigger further development considerations. @replacement@ @@ if (...) -{ -} +info: +puts("surprise"); elfring@Sonne:~/Projekte/Coccinelle/Probe> spatch

<    1   2   3   4   5   6   7   8   9   10   >