Re: [Cocci] [PATCH v3] Coccinelle: Script to replace allocate and memset with zalloc functions

> +@vz1 depends on patch && !context && !org && !report@ > +type T; > +T *d; > +statement S; > +@@ > + > +d = > +-vmalloc > ++vzalloc > + (...); > +if (!d) S > +- memset(d, 0, sizeof(T)); > + > +@vz2 depends on patch && !context && !org &&

Re: [Cocci] Exclusion of else branches from if statements with SmPL

> Did you try it? I think you would need braces around is and es. The software combination "spatch version 1.0.5-00075-g69ba501 compiled with OCaml version 4.03.0" is working to some degree as expected with the following tiny SmPL script. @single_entry@ statement list [1] isl; @@ *if (...) {

Re: [Cocci] Determination of statement list lengths with SmPL

>> Cannot resolve PyUnicodeUCS2_AsEncodedString. Was this issue be fixed by the commit "Updated py.ml for UCS4 support" (fdbafd49c0f2b9267229b105beb870cfc2bd0d06 from 2016-07-16)? >> Can the number of "steps" that were stored by a metavariable of the >> type "statement" also be determined

Re: [Cocci] Determination of statement list lengths with SmPL

> As far as I can see, the only branch available on github is master. The current software (together with the commit 69ba50121a5c80ae91bba16210bd8b281ab8595e from 2016-07-17) seems to work better also for my small SmPL Python script. Thanks for your improvements. Regards, Markus

Re: [Cocci] Determination of statement list lengths with SmPL

Cannot resolve PyUnicodeUCS2_AsEncodedString. I can circumvent this error message also by changing the scripting language. @lengths@ statement list [if_count] isl; statement list [else_count] esl; @@ if (...) { isl } else { esl } @script:ocaml display@ if_n << lengths.if_count;

Re: [Cocci] Determination of statement list lengths with SmPL

>> Cannot resolve PyUnicodeUCS2_AsEncodedString. >> >> >> How should this surprise be fixed? > > Make clean, or maybe make distclean. This suggestion does not help me with the software combination "spatch version 1.0.5-00058-g36edc2b-dirty compiled with OCaml version 4.03.0" at the moment.

Re: [Cocci] Determination of statement list lengths with SmPL

>> Would it make sense to extend the support for statement lists >> in a way which is similar to the other list types in the semantic >> patch language? > > I believe that it is already possible. Do I miss the corresponding description only in the documentation then? "… metadecl ::= …

Re: [Cocci] Determination of statement list lengths with SmPL

> Version 1.0.4 is released. This removes the make of spgen when making > spatch, removes the pre-generated menhir file when menhir is available, > and adds the ability to reason about the lengths of statement lists. I am becoming interested in this functionality a bit more. The

Re: [Cocci] Better documentation around SmPL ellipsis usage?

>> https://github.com/coccinelle/coccinelle/blob/3b52bd3c6960dc996186e1c58c96355db288825c/docs/manual/cocci_syntax.tex#L632 > > About the same as the chance that someone will make a patch suitable for > adding the information. I would find it hard to extract mentioned constraints from the OCaml

[Cocci] Changing return value determination in if statements with SmPL

Hello, I am trying the software combination "spatch version 1.0.5-00058-g36edc2b-dirty compiled with OCaml version 4.03.0" out a bit more with the following approach. @checking_function_calls_directly@ identifier checker, retval, work; parameter list pl; statement is, es; type rt; @@ rt

Re: [Cocci] Object-orientation with SmPL?

> I was also wondering if object orientation threw Coccinelle off. This software provides also a few classes for the programming languages "OCaml" and "Python". Are you thinking about further extensions? Would you like to give the topic "Class libraries for software components" another look?

Re: [Cocci] Coccinelle vs Firefox

> By “somehow”, I sorta left out who would do it (probably me). > Was curious as to whether you thought it a cool idea or not. Your idea might be "cool". But I imagine that you might not like some of the remaining software development efforts. Can such concerns be reduced? Regards, Markus

Re: [Cocci] Transformations for Firefox source files

> With Firefox, it the excision of the bookmarks subsystem from a current > (moving target) > source tree and replacing it with my own. Have you got any ideas already on the ways you would like to filter involved software components? Regards, Markus

Re: [Cocci] Support for more programming languages?

> LLVM has been C++ from the beginning, and GCC is being rewritten in C++, I guess that there are still various software development challenges evolving. > though maybe with enough of a C flavor to be amenable to Coccinelle. How do you think about common properties in the discussed programming

Re: [Cocci] Transformations for Firefox source files

> So my question is whether you guys think Coccinelle would be useful to me > in comprehending and doing MASS transformations of the firefox source? For which kind of source code transformations are you especially interested in? With which search patterns would you like to achieve further

Re: [Cocci] Support for more programming languages?

> The main problem is that firefox is written in a variety of programming > languages. https://www.quora.com/What-programming-languages-are-web-browsers-like-Google-Chrome-Opera-and-Mozilla-Firefox-written-in > How hard would it be to retarget Coccinelle to those languages? The Coccinelle

[Cocci] Configuration challenges around font "ifgeo"?

Hello, I stumble on the following surprise. elfring@Sonne:~/Projekte/Coccinelle/20160205> LANG=C make docs … kpathsea: Running mktexpk --mfmode / --bdpi 72 --mag 1+0/72 --dpi 72 ifgeob10 mktexpk: Mismatched mode ljfour and resolution 72; ignoring mode. mktexpk: Can't guess mode for 72 dpi

[Cocci] Checking updates for documentation generation

Hello, I have noticed the commit "Removed docs from default make targets". https://github.com/coccinelle/coccinelle/commit/2b3a75bb5a0b6f0ab0f6e089db56d9140b1642c7 I have tried the following command out then. elfring@Sonne:~/Projekte/Coccinelle/20160205> make docs … /usr/bin/ocamldoc -I

Re: [Cocci] Checking build dependencies for "Menhir"

I have gathered a bit more background information. AC_REQ_COCCI_EXTPKG([menhirLib]) ⇒ AC_COCCI_OCAMLPKG() ⇒ AC_CHECK_OCAML_PKG() ⇒ $OCAMLFIND query … configure: configuring package menhirLib checking for OCaml findlib package menhirLib... not found … The mentioned steps from m4 scripts

Re: [Cocci] Checking build dependencies for "Menhir"

>> Is the bundled Menhir version currently required for a working >> Coccinelle software? > > No, you can use a more recent version of Menhir if you want. … checking for menhir... /usr/local/bin/menhir configure: system menhir will be used … File "parser_cocci_menhir.mli", line 262, characters

Re: [Cocci] Checking build dependencies for "pyml"

> There are things like line numbers that are converted to strings. I am affected by such an implementation detail in some SmPL scripts. > There is no technical reason for that, but the person who first > implemented the python interface did that, and then it didn't seem like > big enough of a

Re: [Cocci] Checking build dependencies for "Menhir"

> > Is the bundled Menhir version currently required for a working > > Coccinelle software? > > No, you can use a more recent version of Menhir if you want. I would appreciate that. I am struggling to complete the needed dependencies for current releases of various OCaml software. > The

Re: [Cocci] Checking build dependencies for "pyml"

> > Will the mapping (and corresponding data type conversion) will need > > another look for integer values in this use case? > > The mapping is unchanged. How do you think about to achieve that integers will be preserved (without conversion to strings) here? Regards, Markus

Re: [Cocci] Checking build dependencies for "Menhir"

> > /usr/bin/ocamlc.opt -unsafe -I ../commons -I ../commons/ocamlextra -I > > ../globals -I /home/elfring/Projekte/Coccinelle/20160205/bundles/menhirLib/ > > -c parser_cocci_menhir.mli > > File "parser_cocci_menhir.mli", line 262, characters 10-56: > > Error: Unbound module

Re: [Cocci] Checking build dependencies for "pyml" (and Menhir)

>> make[2]: *** @MAKE_pyml@: No such file or directory. Stop. > > Thank you for the report. Does this error continue to happen if you > delete the subdirectory autom4te.cache/ and then execute ./autogen, > ./configure, etc.? Did a configuration script become outdated? -rwxr-xr-x 1 elfring users

Re: [Cocci] Adding parameter to function if missing

> +++ /tmp/cocci-output-7971-016dcc-test.c > @@ -1,9 +1,9 @@ > void f1(void *args) { > -bar(anything); > +bar(foo, anything); > } > [...] > All call are replaced and no header are modified. Would you like to achieve such source code transformations also in

Re: [Cocci] [PATCH v2 2/3] docs/manual/cocci_syntax.tex: extend with python iteration

> Signed-off-by: Luis R. Rodriguez Would a short commit message be nice here? > +example with ocaml is fond in {\tt demos/iteration.cocci}, a python * How do you think about the programming language name "OCaml"? * Another typo correction: … found … Regards, Markus

Re: [Cocci] [PATCH v2 1/3] docs/demos: add a few ++ documentation and demos

> +Coccinelle allows for transformations to enable modifying C code using Can the word "for" be omitted here? > +You may run into the situation where grammar you specificy for Did you overlook to fix a typo here once more? … specify … > +in code, in such cases Coccinelle cannot gaurantee

Re: [Cocci] [PATCH] bundles/pycaml/: force pycaml preparation to be done serially

>> It makes parallel building work with a minimal change. The bigger >> hammer is to not trust any bundles and add +.NOTPARALLEL: all to >> the top level bundles/Makefile, that was my first approach, however >> it didn't seem like a good idea either as then you'd slow the bundle >> build

Re: [Cocci] scripts: add glimpse.sh for indexing the kernel

> To me what we can best do is see what we can take out of agrep, > and port it to proper GNU grep, then see if git can also enable > complex queries as Julia notes. How do you think about to improve such tools together with computation tree logic? ;-) Regards, Markus

Re: [Cocci] [PATCH v2 4/8] scripts: add glimpse.sh for indexing the kernel

> I'm not sure that this is worth it. It adds a dependency on a tool > that seems not to be well maintained. Would any developers like to achieve further software improvements by additional means? How are the chances for corresponding progress from an approach like in a repository by Luis?

Re: [Cocci] scripts: add glimpse.sh for indexing the kernel

> http://webglimpse.net/ > Its vaguely mentioned there. That's as good as it gets... How do you think about to insert the date "2014-09-26" into your commit message? >> https://github.com/gvelez17/glimpse/ > Sadly the original release didn't compile, I reported the issue in hopes it > would >

Re: [Cocci] [PATCH 2/4] scripts: add reqs python library

> +class Req: Will a longer identifier like "requirement" be more useful than the suggested abbreviation? > +"To be used for verifying binay package dependencies on Python code" Would you like to fix a typo here? ... binary ... > +def req_old_program(self, program, version_req):

Re: [Cocci] [PATCH v3 4/6] coccicheck: add indexing enhancement options

> +DIR=$(dirname $(readlink -f $0)) > +DIR="${DIR}/../" How do you think about to merge these variable assignments also into one? +DIR="$(dirname $(readlink -f $0))/../" Regards, Markus ___ Cocci mailing list Cocci@systeme.lip6.fr

Re: [Cocci] [PATCH v3 3/6] scripts: add glimpse.sh for indexing the kernel

> Glimpse is a tool you can use to index the kernel. > The tool was recently open sourced under the ISC license > and can be obtained at: Do you find any official announcement for this software evolution? Is the wording "recent" really appropriate if you would eventually like to refer to a

Re: [Cocci] [PATCH 3/4] scripts: add glimpse.sh for indexing the kernel

> Glimpse is a tool you can use to index the kernel. The tool > was recently open sourced under the ISC license and can be > obtained at: How do you think about to mention the script addition also directly in the commit message? > @@ -0,0 +1,12 @@ > +#!/bin/bash > + > +DIR=$(dirname $(readlink

Re: [Cocci] [PATCH 4/4] coccicheck: add indexing enhancement options

> in practice though this seems to not perform better than > regular grep however its expected to help with some use cases > so we use that if you have no other indexing options in place > available. Would you like to fix a typo in this paragraph? Regards, Markus

Re: [Cocci] [PATCH 2/4] coccicheck: enable paramap support

> Also enable the load balancing to be dynamic, so that > if a thread finishes early we keep feeding it. Is this functionality influenced by the parameter "chunksize"? Regards, Markus ___ Cocci mailing list Cocci@systeme.lip6.fr

Re: [Cocci] [PATCH 0/4] scripts/coccicheck: add paramap and indexing options

> we should be able to also take advantage of with coccicheck, > the most important one is paramap support. Do OCaml developers prefer to refer to the software "Parmap" here? https://rdicosmo.github.io/parmap/ Regards, Markus ___ Cocci mailing list

Re: [Cocci] [PATCH] docs/demos: add ++ transformation documentation and demos

>>> This perhaps is not the best demo for use of ++ but it >>> should suffice. >> Since which release of the Coccinelle software is this notation (double >> plus) supported? > It's many years old. As a random guess I would say 2010. Is there any more functionality waiting for detailed

Re: [Cocci] [PATCH] docs/demos: add ++ transformation documentation and demos

> This perhaps is not the best demo for use of ++ but it > should suffice. Since which release of the Coccinelle software is this notation (double plus) supported? > This adds some basic documentation for it and a demo. Thanks for your approach. > @@ -0,0 +1,28 @@ > +/* > + * This can move

Re: [Cocci] [PATCH] docs/demos: add ++ transformation documentation and demos

> @@ -851,6 +851,11 @@ rule should apply if rule XXX was never matched at all. > > \section{Transformation} > > +Coccinelle allows for transformations to enable modifying C code using How do you think about to omit the word "for" here? > @@ -1100,6 +1105,138 @@ write > Some kinds of terms

Re: [Cocci] Further software updates after Coccinelle v1.0.5?

> As far as I can see, the current contents of version say 1.0.5. Now I can see also the desired revision identifier by a corresponding commit from 2016-06-03 (which I missed yesterday). https://github.com/coccinelle/coccinelle/commit/8906ed7e4dda8bd6642d4bd0dfa022e7a119f406 I am curious on how

Re: [Cocci] Further software updates after Coccinelle v1.0.5?

> There is a tag for the current revision. As it says on the Coccinelle > website, 1.0.5 was actually released on June 2. I only had time to make > the announcement today. How do you think about to fix the version file at least?

Re: [Cocci] Further software updates after Coccinelle v1.0.5?

> >> * I would appreciate that corresponding changes will become viewable >> also by the GitHub interface shortly. > I have no idea what you are asking for. The file changes.txt is availabl > in github all the time. 1. I have noticed that the last published commit seems to refer to a merge

Re: [Cocci] Further software updates after Coccinelle v1.0.5?

> Coccinelle v1.0.5 is now available. Thanks for this software development progress. * I would appreciate that corresponding changes will become viewable also by the GitHub interface shortly. * Would you like to add any comments to open issues like the following? > * Coccinelle is compatible

Re: [Cocci] Checking further software revisions?

>> I have 4.01, and configure works fine. > FWIW, I was on 4.01 and I tried again had the same pcre symbol issue. > I upgraded to ocaml 4.02 and it now compiles fine. Do you suggest to check any more version combinations from bundled and/or installed software for your build system? Regards,

Re: [Cocci] Improvements for building the Coccinelle software

>> How will the build scripts evolve further? > > We will continue to send pull requests as needed. Would you like to add any comments to remaining open issues? Regards, Markus ___ Cocci mailing list Cocci@systeme.lip6.fr

Re: [Cocci] Improvements for building the Coccinelle software

> The other usages of '[$]' (which seems to be some kind of escape) are fine. Thanks for such a clarification. > Its just the invocation of AC_COCCI_FINDTOOL with wrong arguments > that needs fixing. Will it be interesting to look at the circumstances under which this update candidate was

Re: [Cocci] Improvements for building the Coccinelle software

> There is now a pullrq to fix a bug in configure.ac, I am curious when the script "setup/cocci.m4" will be updated. https://github.com/coccinelle/coccinelle/pull/70 Would you like to improve the involved build scripts any more? https://github.com/coccinelle/coccinelle/issues/42 > and also a

Re: [Cocci] Deletion of indication for "optional" syntax elements?

> At what place do you have in mind? Was an update for one place enough? more correct about requirements on function prototypes https://github.com/coccinelle/coccinelle/commit/51a2709600bc7e0051cabbebe0005ee61e235600 Regards, Markus ___ Cocci mailing

Re: [Cocci] Deletion of indication for "optional" syntax elements?

>> Would you like to delete the specification "\opt" at a few places? >> https://github.com/coccinelle/coccinelle/blob/df648d123ac4dad16a855f0c5f3adf42ce602b29/docs/manual/cocci_syntax.tex#L1173 > At what place do you have in mind? The return type of a functin > definition really is optional.

Re: [Cocci] Deletion of indication for "optional" syntax elements?

>> Looks to me then that the grammar documentation should not indicate >> the fn_ctype as optional for function prototypes >> (http://coccinelle.lip6.fr/docs/main_grammar006.html)? > Indeed. I'll fix that. Would you like to delete the specification "\opt" at a few places?

Re: [Cocci] [PATCH v2 3/3] coccinelle: add control flow documentation

> I edited the text somewhat. Questions like "Do you want to rephrase > this?" I don't really know what to do with. I find a commit with a subject like "adjust the control flow discussion a little" also interesting for this issue.

Re: [Cocci] [PATCH v2 3/3] coccinelle: add control flow documentation

>> Did you fix the remaining open issues (like typos) in this update >> suggestion? > I edited the text somewhat. Can corresponding commits be viewed in a public repository in the near future? Regards, Markus ___ Cocci mailing list

Re: [Cocci] [PATCH v2 3/3] coccinelle: add control flow documentation

> Applied Did you fix the remaining open issues (like typos) in this update suggestion? Regards, Markus ___ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] [PATCH v2 3/3] coccinelle: add control flow documentation

> + #spatch --control-flow-to-file flow1.c Do you really want to add such commands as comment lines of this make file? > +Rules describe a property which Coccinelle must match, when the property > +described is matched the rule is considered successful. Program control > +flows vary, a

Re: [Cocci] [RFC 3/3] coccinelle: add control flow documentation

> +this rule by providing additional requirements and usign ellipses in between. Will the wording "using" be better here? > +or that the statements in between must be present at leaset once (<+... > ...+). Please fix another typo: least. How do you think about to add any references (or

Re: [Cocci] Build configuration challenges around "Menhir"

>> Who will dare to tackle open issues there a bit more? > > In a general sense, perhaps no one. I tried several times to improve corresponding software development challenges. I am curious when more ideas will be picked up also by other contributors. > If you have a specific issue in mind

Re: [Cocci] Build configuration challenges around "Menhir"

>> error: the file parser_cocci_menhir.ml is needed, which requires >> preprocessing by menhir to obtain it from parser_cocci_menhir.mly. >> However, menhir is not enabled. > > Indeed, it is not there. I guess it was decided that people who use > github should have the capability to generate

Re: [Cocci] remove redundant const qualifiers from function arguments

> I guess that is a valid optimization. But does this go through the > parsing step? And even if, why doesn't mine? Would you like to try the following SmPL approach once more? @prototype_adjustment@ identifier F, I; type R, T; @@ R F(..., -const T I, ... ); Regards, Markus

Re: [Cocci] remove redundant const qualifiers from function arguments

> I think I have a test case that is minimal. How do you think about to try a bit more fine-tuning out for the shown Coccinelle scripts? How much will it matter for your change pattern to specify only the deletion of the qualifier "const" from a data type of a function parameter while leaving

Re: [Cocci] Out of tree instrumentation with coccinelle demo

> You can fetch it here: > https://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/cocci-tact.git * Can any source files be also reviewed by a web interface? * Under which addresses would you like to discuss the suggested software developments? Regards, Markus

Re: [Cocci] [PATCH 5/5] pycocci: enable SmPL <=> Patch equivalence tests

> We can extend Coccinelle's existing test framework to support > multiple files, header files, but a different can also consist > of making use of SmPL <=> Patch equivalence support. Instead of > relying on .res files, this relies on patches that provide > a outline of differences using standard

Re: [Cocci] spatch temporary files issues

> I would expect software to make temporary files and directories at other > locations, > such as how perl provides the mktemp interface, so that files are safe from > invocation like this. * Have you got any preferences for a corresponding directory selection? * Would you like to specify any

Re: [Cocci] spatch temporary files issues

> That's essentially what I did as a work around. It just surprised me > that there is no way to control how temporary files get created. It seems that have got some control in such an use case already. The user interface might not be as convenient as you would prefer. Should a temporary

Re: [Cocci] spatch temporary files issues

> I am using coccinelle for a project, and have run into an issue regarding the > temporary director created by spatch when it runs on a given cocci file. > > Fatal error: exception Failure("Directory memcpy-assign used for temporary > files already exists and should be removed.") > > This

Re: [Cocci] Parsing C source files by Coccinelle

> Imagine that you are interested in finding uses after free. You may write a > pattern more or less like > >kfree(x); >... when != y = E >z > > If you say "when != x = E" you can miss cases in which `x' is assigned > through an alias, > but with "when != y = E" that would match

Re: [Cocci] Parsing C source files by Coccinelle

> Some features would need a proper integration with Coccinelle though, Have you got any further details in mind already? > and that's another nontrivial task. Do you know any more software developers who would like to help here? Regards, Markus ___

Re: [Cocci] Parsing C source files by Coccinelle

> If you are talking about using Coccinelle as a bug finder, > and empower it with alias analysis, I am also curious on how such technologies will fit together. > then I have spent about a year working on a similar idea. How similar was this approach? > I am available to discuss my

Re: [Cocci] Parsing C source files by Coccinelle

>> The software library "http://cristal.inria.fr/~fpottier/menhir/; >> is involved to some degree. > > No, not for parsing C. Currently, Menhir (an advanced alternative to > ocamlyacc) is used only to generate the SmPL parser, not the C parser. Thanks also for your clarification. Would the

Re: [Cocci] Parsing C source files by Coccinelle

>> The software library "http://cristal.inria.fr/~fpottier/menhir/; >> is involved to some degree. > > None whatsoever, actually. An option like "--enable-menhirLib" is provided under the configuration category "Optional Features", isn't it? > A parser is implemented using ocamlyacc, combined

Re: [Cocci] Parsing C source files by Coccinelle

> In particular, we would like to see whether it is possible to improve > Coccinelle results > by supplying it with aliasing information about variables. Does such a goal indicate that you are going to experiment also with data flow analysis? > On executing, > * > spatch -sp_file

Re: [Cocci] Regeneration of the script "configure" for Coccinelle

> Me and my team mates have been recently working on program analysis, > and are very keen on working with your tool. I am curious in which directions you would like to experiment with this software further. > Unfortunately, we faced a compilation problem. I find that this issue does not

Re: [Cocci] coccinelle: also catch kzfree() issues

>>> Coccinelle doesn't make any optimizations based on regulat expressions. >> >> Where can your software optimise the source code search? > > When the name appears explicitly in the matching code, Coccinelle will > parse and process only files that contain that name. Does your software perform

Re: [Cocci] coccinelle: also catch kzfree() issues

>> @free@ >> +identifier kfree =~ "kz?free"; > > Thanks for the suggestions. However, the regular expression is not such a > good idea. How much is such a SmPL constraint still usable then? > Coccinelle doesn't make any optimizations based on regulat expressions. Where can your software

Re: [Cocci] coccinelle: add style check for assignment in if

>> Can the check result display be more convenient from the semantic >> patch script interface in comparison to the other tool? > > -ENOPARSE. More detail please. Kris Borer suggested a SmPL script which can generate (only) patches so far by the usual application of the Coccinelle software. I

Re: [Cocci] coccinelle: add style check for assignment in if

>> Would you like to consider also the reuse of SmPL variables >> like "org" and "report"? > > I think that there is no point for these things, because checkpatch > already gives warnings about this issue. Can the check result display be more convenient from the semantic patch script interface

Re: [Cocci] The Coccinelle repository on GitHub

> The two repositories are totally incompatible. Thanks for another clarification around the handling of a previous partial and the complete software development history. >> Are there any chances to achieve that a command like "git checkout master >> && git pull" will also work without merge

Re: [Cocci] The Coccinelle repository on GitHub

>> Will any special branches be introduced in the near future? > > Not that I know. Would you like to clarify the application of "advanced" software development methodologies any further? It seems that there are only two committers active in the leading Git repository for this software at the

Re: [Cocci] The Coccinelle repository on GitHub

> For those of you who were downloading Coccinelle from GitHub, we recommaend > that you remove your current clone of the GitHub repository and do a fresh > > git clone https://github.com/coccinelle/coccinelle.git Do try to indicate that the previous GitHub repository was not really compatible

Re: [Cocci] The Coccinelle repository on GitHub

>> Is it correct that no additional (topic) branches are provided so far? > > Yes. Thanks for your clarification. > The team does not use such branches to collaborate, at a team level. I find this information surprising. >> Are there any plans to adjust the affected software development

[Cocci] Extending source code at file end with SmPL

Hello, I became interested in another source code transformation. I would like to append something to selected source files at the end. How should the "file end" be expressed for the semantic patch language? Regards, Markus ___ Cocci mailing list

Re: [Cocci] Extending source code at file end with SmPL

>> Would it make sense to clarify any further extensions? > > Why don't you just use cat? A software tool like "cat" does usually not generate the desired patch file. I would also appreciate if the input file will be checked according to specific source code search patterns. Regards, Markus

Re: [Cocci] Extending source code at file end with SmPL

>> How should the "file end" be expressed for the semantic patch language? > > There is no convenient way to express this. You could perhaps match all > of the function definitions, find their line numbers, and put something > after the last one. Thanks for your feedback. How are the chances

Re: [Cocci] Extending source code at file end with SmPL

>> I would also appreciate if the input file will be checked according to >> specific >> source code search patterns. > > I guess you can generate what you want with Coccinelle, and then cat it > onto the end of some other file and do diff to get a patch. I am looking for possibilities to keep

Re: [Cocci] Filter out field names

>@safe@ >position p1; >identifier virtual.ty; >struct ty *x; >identifier f; > @@ > > \(spin_lock\|spin_lock_irqsave\)(>lock,...) Can this SmPL specifcation be extended a bit easier if the suggested disjunction would be written like the following instead? (spin_lock |spin_lock_irqsave

Re: [Cocci] script code on metavariables

> Some time ago, the idea of putting constraints expressed as scripts was > discussed > (http://article.gmane.org/gmane.comp.version-control.coccinelle/1928). I am curious if the discussion (from December 2011) will be continued around a topic like "assignments and support for SmPL rule

Re: [Cocci] script code on metavariables

>>> The expression should return true or false, ie true if the proposed value >>> of p is acceptable as a match, and false if it is not. >> >> Do you describe the introduction of generic predicate functions here? > > I don't understand the question. I try another wording … > In any case, the

Re: [Cocci] script code on metavariables

> I don't know what is meant exactly by a method call, but anything that > looks like a valid C expression is fine. The code will not be interpreted > by Coccinelle, only by the relevant scripting language, which is currently > only OCaml. Would an other wording fit also? The returning of a

Re: [Cocci] script code on metavariables

> It is not possible to write an OCaml function definition that has the form > of a C expression. In practice, it is likely that one would only make a > function call, like I showed in my example. Are method calls are also supported there depending on the reused programming language? >> Does

Re: [Cocci] Documentation check for parallelisation support?

>> Will this aspect need further considerations because of the evolving >> parallelisation support? >> https://github.com/coccinelle/coccinelle/issues/50 > > I believe that parallelism with -j only fails if there is a finalize. > An initialize by itself should be OK. Does the corresponding

Re: [Cocci] Build failure on ppc64le: Failure("dump: impossible tag (1002)")

> But note I'm not saying this is not a compiler bug. > We've had a few. Interesting … How do you think about to share any more information about the last working system configuration for your special build environment? > Is there a test case you could send me? In which kind of test scripts

Re: [Cocci] [PATCH v2] coccinelle: api: check for propagation of error from platform_get_irq

>> https://cwe.mitre.org/data/definitions/252.html > > The value is not unchecked. Would you like to express any stronger relationship between the function call example and the occurrence of an if statement by the discussed SmPL script? > I made a specific rule because the specific problem is

Re: [Cocci] [PATCH v2] coccinelle: api: check for propagation of error from platform_get_irq

> The error return value of platform_get_irq seems to often get dropped. How do you think about any more fine-tuning here? Commit message: * … of the platform_get_irq() function seems to get dropped too often. * Why do you concentrate on a single function name? Do you plan to extend this

Re: [Cocci] Coccinelle for other programming languages

> What is the effort it will take to come up with a Coccinelle for dynamic > languages > such as Python, JavaScript, etc. Would you like to improve any software design elements from compiler technology like the following? 1. Token stream 2. Abstract syntax tree 3. Control flow graph > Which

Re: [Cocci] Coccinelle for other programming languages

>> I’m curious whether you can comment on any other tools for other programming >> languages. How do you think about to take another look at issues like the following? > Coccinelle doesn't support any languages other than C, and a small amount of > C++. Support C++ codebases

Re: [Cocci] Coccinelle for other programming languages

>> It could be conceptually possible to design a version of Coccinelle >> for other languages, but it would require a lot of development work, >> so funding would be required. > > And if you ask me, anyone not funding such endeavours, are simply insane, Have you got any contacts to contributors

Re: [Cocci] Finding labelled statements with SmPL

> The labels for switch have "case" in front of them. They won't be matched > by a pattern like label: I would expect that the key word "case" can be optional because such source code should be matched by the specified SmPL ellipsis. Regards, Markus

[Cocci] Finding usage of the statement "goto" with SmPL

Hello, I have tried another tiny SmPL script out. @jumping@ identifier label; @@ *goto label; This test example works as expected. elfring@Sonne:~/Projekte/Coccinelle/janitor> spatch.opt show_goto_usage1.cocci ~/Projekte/Linux/next-patched/drivers/block/zram/zram_drv.c … @@ -1424,7 +1400,6

<    1   2   3   4   5   6   7   >