> 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?
>
>> * 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
> 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
>> 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,
>> 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
> 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
> 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
> 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
>> 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.
>> 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?
> 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.
>> 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
> 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
> + #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
> +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
>> 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
>> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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
___
> 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
>> 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
>> 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
> 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
> 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
>>> 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
>> @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
>> 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
>> 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
> 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
>> 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
> 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
>> 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
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
>> 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
>> 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
>> 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
>@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
> 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
>>> 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
> 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
> 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
>> 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
> 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
>> 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
> 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
> 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
>> 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
>> 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
> 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
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
> So trying to find those in-tree drivers which _do not_ define a cleanup
> method with coccinelle, led to this fragment which has a parse error.
>
> Apologies if my question is obvious or trivial;
Your support request is fine. - You show just another interesting use case.
The preferred
> virtual context
>
>
>
> @ is_tty @
>
> identifier fops;
>> The solution would be to take the position of each one, and then save only
>> the position of the earliest one. This would require using scripts and
>> hash tables, and is kind of clunky.
>
> Maybe I'm better off just using sed or perl for this job?
Would you dare to try the semantic patch
Hello,
The Coccinelle software takes special care for some details from source files.
These details correspond to specific data structures which are connected with
a syntax for their elements. Each structure member needs usually to be processed
in the context of the involved data type hierarchy.
Hello,
How many software developments and further fine-tuning are necessary
to get scripts for the semantic patch language working together
with various libraries for the programming language "OCaml"?
https://github.com/coccinelle/coccinelle/issues/19
> You would have to give an example.
Should an approach like the following which is derived from
the script "demos/conjunction.cocci" also work?
@@
identifier f;
@@
-f
+m
(...,3,...);
...
g(...,3,...);
...
f(...,
- 8
+ 80
,...);
...
g(...,8,...);
Regards,
Markus
> If you have two separate rules, they can match anywhere.
I became interested to compare the effects from the added functionality
to the use case where several changes would be applied in a specific SmPL rule
without an ampersand specification as in previous versions.
Regards,
Markus
> The code is not intended to be run.
I guess that a duplicate function name can result in unwanted data
from the analysis for a source file like "demos/conjunction.c", can't it?
Regards,
Markus
___
Cocci mailing list
Cocci@systeme.lip6.fr
> demos/conjunction.c is only intended for use with demos/conjunction.cocci,
> which doesn't care at all about the name of the containing function.
Will this source code example become a bit easier to understand
if one of the test functions will be renamed so that the names are unique?
Regards,
> * There is now support for conjunctions ( & ... & ). As for a
> disjunction, the () and & should be in column 0. A conjunction requires
> two patterns to match against a given piece of code in a consistent way.
When will corresponding descriptions appear also in the manual?
How does this
>> Are you interested in achieving progress on a topic like
>> 'Collateral evolution around "Automake"'?
>> https://github.com/coccinelle/coccinelle/issues/41
>
> Sort of.
I am curious if you would like to contribute a bit more help
for the affected design details.
> If a tarball ships
> 1. Running `aclocal; autoconf` is not enough. I spot a Makefile.am
> in the source tree, so you more or less need `autoreconf -fi`
> instead in the "autogen" script.
Are you interested in achieving progress on a topic like
'Collateral evolution around "Automake"'?
> Since coccinelle.spec does not invoke autoreconf
How does the script
"https://github.com/coccinelle/coccinelle/blob/a46bef70162d17cec6b0fc6101d737989f735ee4/autogen;
fit to your view?
> or any of the developer-side regenration tools,
Do you see any more software evolution there?
> we do
> Remove removal and re-addition of freeing functions.
I find such a wording confusing for a commit message.
> Add position variable on usb_free_urb in the non-patch case.
Is it interesting that this fix corresponds to a bug report from 2014-08-09?
https://lkml.org/lkml/2014/8/9/33
> So far, the issue is that I was absolutely not able to reproduce it,
> so any help on this would be greatly appreciated.
I have got the impression that such an issue depends on specific version ranges
for the software "OCaml" and "Menhir".
Do you know the versions with which this library will
> Error: The files /usr/lib64/ocaml/obj.cmi
>and /usr/lib64/ocaml/menhirLib/menhirLib.cmi
>make inconsistent assumptions over interface Obj
> Makefile:90: recipe for target 'parser_cocci_menhir.cmx' failed
I stumbled on the following message since I installed
the package "OCaml
>> How do you think about the reuse of the parameter "--recursive-includes"
>> here?
>
> Last time I have tried it, kernel source check took more than 10 hours,
> so I gave up.
This is interesting background information.
There are opportunities for more fine-tuning of such a source code
> Generally I want to catch all assignments of signed function result to
> unsigned var.
Such a static source code analysis will be useful to some degree.
> In this script I have implemented it this way:
> 1. Look for all assignments 'unsigned = signed' (rs rule).
> 2. Check if signed from rs
>> The connection between the SmPL specification "f(...)@e" and the desired
>> return type
>> was not obvious for me so far.
>
> The nearest enclosing expression of the ) is the whole function call itself.
Thanks for your explanation.
Now I guess that the enclosing context is a particular
>> Are there any risks to include too many functions?
>
> Maybe if there are conflicting definitions of the function with different
> return types. This is probably not a big deal in practice.
Are there any more concerns around the handling of conditional source code
analysis for Linux
> It doesn't matter, as long as the type is available.
I suggest to make the circumstances better known when this will be the case.
>> How do you think about reuse another data type enumeration there?
>
> No idea what you mean by this.
A SmPL variable can also be connected with a data type
>> * Will a command-line parameter like "--include-headers-for-types"
>> be needed here?
>
> This argument is never needed. It is only an optimization. It means that
> he header files are only considered when collecting type information, but
> not whn doing transformation. But this argument
>>> +@rs@
>>> +position p;
>>> +typedef bool, u8, u16, u32, u64, s8, s16, s32, s64;
>>> +{char, short int, int, long, long long, s8, s16, s32, s64} vs;
>> Can it matter to specify also the type modifier "signed" in this SmPL
>> approach?
>>
> +@rs@
> +position p;
> +typedef bool, u8, u16, u32, u64, s8, s16, s32, s64;
> +{char, short int, int, long, long long, s8, s16, s32, s64} vs;
Can it matter to specify also the type modifier "signed" in this SmPL approach?
http://coccinelle.lip6.fr/docs/main_grammar005.html#ctype_qualif
>
> In the example above spatch finds ull, ulli, but not ul and uli.
> If you add int to unsigned long long, it won't find anything.
I suggest to take another look at the use of type modifiers
in the semantic patch language. It seems that it matters occasionally
to specify them explicitly.
How do
> If you mean adding int to 'unsigned long [long]' types, it does not work.
> For some reason it works only without adding int after long.
Do you get any error message for this SmPL approach?
With which source files do you try the extended SmPL script out?
Regards,
Markus
> v3: added bool type
I would appreciate a bit more feedback for my concerns around your
evolving approach.
* Reuse of "long int"?
* Splitting of the suggested SmPL rule so that each source code check
will be connected with appropriate warning messages.
Will any more fine-tuning be useful?
>> * Reuse of "long int"?
> If you mean adding int to 'unsigned long [long]' types, it does not work.
I am surprised.
> For some reason it works only without adding int after long.
The Coccinelle software should support the term "generic_ctype" from
the SmPL grammar so far, shouldn't it?
> https://btrlinux.inria.fr/coccinelle/
…
> However, I would be very interested in feedbacks to adjust
> what is already there and improve the quality of further additions.
I would prefer the header "… to find source code" before the five
examples "Match …" (because they do not deal with "bugs").
> As we discussed earlier I have dropped idea of adding v <= 0 as it is widely
> used in checking ranges, counters, quantities.
I find that such a design decision will need more fine-tuning of the suggested
small SmPL script.
> +@r depends on context || org || report@
> +position p;
> +typedef
> +@r depends on context || org || report@
> +position p;
> +typedef u8, u16, u32, u64;
Can the involved data types be restricted for unsigned types for such
a source code analysis in a more general way?
> +{unsigned char, unsigned short int, unsigned int, unsigned long, unsigned
> long long,
>> v@p
>> (
>> *< 0
>> |
>> *<= 0
>> )
>
> It does not, and is not intended to, work. The branches of a disjunction
> should be complete expressions.
Will the following SmPL approach be more appropriate then?
(
*v@p < 0
|
*v@p <= 0
)
Regards,
Markus
> If you think about removing all u* typedefs
I became interested in the use case to consider more type definitions
besides the ones which should usually be handled for Linux source files.
> it will result in omitting u* related comparisons,
> unless you use --recursive-includes option.
How do
> --recursive-includes is already a parameter.
I am unsure if its effect on source code analysis speed will matter here.
> size_t is also unsigned.
Will such a specification work also without an explicit SmPL typedef?
Regards,
Markus
___
Cocci
> I want to check whether all accesses to any part of some struct are locked.
I imagine that you will need to perform data-flow analysis for such a task.
I guess that there are some software development challenges to achieve
it with the semantic patch language.
> struct B *b;
> ...
>
> I'm sticking with 1.0.2 now that Julia has highlighted that the fault
> was mine in not removing the comma :)
I find it just interesting that such a detail was discovered by your
version comparison.
There might further situations situations follow where it will be also
useful to experiment
> On that note, it might make sense to add multithreading or
> multiprocessing.
Did you try out to pass the parameter "--jobs" to a current version of
the command "spatch"?
Would you like to experiment with parameters "--index" and "--max"?
Regards,
Markus
> Reviewing the changes made by my s-patch, I've come across the following hunk
> :
How do you think about to show your semantic patch script here?
> +++ b/drivers/hwmon/jc42.c
> ...
> @@ -529,13 +529,7 @@ static const struct dev_pm_ops jc42_dev_pm_ops = {
> #define JC42_DEV_PM_OPS
> There is a comment section below, and the hunk removes the first /*
> there instead.
Does this generated update suggestion fit to your expectations?
Would you like to express any preferences if specific comments should be
deleted together with some source code or when such annotations should
> Spatch available at: https://gist.github.com/kbingham/96477177dd20a72b1c2f
>
> Run it on a linux kernel tree:
>
> with spatch v.1.0.2 I get the following:
>
> kbingham@CookieMonster:/opt/projects/linaro/hikey/kernel$ spatch
> --linux-spacing --sp-file patches/i2c-dt.cocci . --in-place
>
> I think the bundle approach is favoured because the Objective Camllanguage
> and its libraries are not as widespread as gettext and libtool.
> So the idea of the bundles is tomake life of end-users simpler,
> but of course it also makes thelifeofdevelopers and maintainers
> a bit harder.
The
> So, is there a way to have all these macros that detect the OCaml-related
> tools integrated to the autoconf distribution?
Yes.
Are there any more software developers who would like to contribute
their macros to the GNU Autoconf Archive so that more programming languages
can be directly
> The tool is distributed with the libraries it depends on
> (they are provided as bundles).
This approach is generally fine in principle.
> For each dependency, coccinelle's configure script checks whether the
> library is already installed. If not, the system is prepared to use the
> bundled
1101 - 1200 of 1468 matches
Mail list logo
