Re: [Cocci] Adjustment for const qualification

2018-08-15 Thread SF Markus Elfring
>> How do you think about to try the following SmPL script variant out? >> >> @replacement@ >> @@ >> -const >> +__genl_const >> struct >> ( >> genl_multicast_group >> |genl_ops >> ) > > This is rejected by the semantic patch parser. Can my update suggestion make sense if the parsing software wi

Re: [Cocci] Adjustment for const qualification

2018-08-15 Thread SF Markus Elfring
> https://git.kernel.org/pub/scm/linux/kernel/git/backports/backports.git/tree/patches/0027-genl-const/genl-const.cocci How do you think about to try the following SmPL script variant out? @replacement@ @@ -const +__genl_const struct ( genl_multicast_group |genl_ops ) Regards, Markus

Re: [Cocci] Compacting parameters into fewer lines

2018-07-31 Thread SF Markus Elfring
>> @rule1@ >> expression x; >> expression list y; >> @@ >> -DBG_PRINTF >> +NV_PRINTF >>    ( >> -  (x), >>     y); > > This doesn't work: Do you care if a macro (or function) parameter is optionally enclosed by parentheses? > -    DBG_PRINTF((DBG_MODULE_OS, DEBUGLEV

Re: [Cocci] Compacting parameters into fewer lines

2018-07-31 Thread SF Markus Elfring
> Attached. I have taken this transformation approach as an opportunity to take another look at implementation details for further software development considerations. @rule1@ expression x; expression list y; @@ -DBG_PRINTF +NV_PRINTF ( - (x), y); You repeated add

Re: [Cocci] Search/replace inside string constants?

2018-07-27 Thread SF Markus Elfring
> @script:python s@ > c << r.c; > c2; > @@ > if c.startswith('"NVRM: '): > coccinelle.c2 = '"' + c[7:]; > else: > coccinelle.c2 = c; I have got another software development idea for this transformation approach. The detection of unwanted prefixes could be moved into a regular expression li

Re: [Cocci] Search/replace inside string constants?

2018-07-27 Thread SF Markus Elfring
> @script:python s@ > c << r.c; > c2; > @@ > if c.startswith('"NVRM: '): > coccinelle.c2 = '"' + c[7:]; > else: >coccinelle.c2 = c; I suggest to reconsider the action if no modification should be performed finally. How do you think about to use the statement “cocci.include_match(False)” i

[Cocci] Applicability of SmPL inheritance?

2018-07-08 Thread SF Markus Elfring
Hello, I would like to clarify another combination of functionality from the semantic patch language. The following small SmPL script can be constructed to find some function calls. @rtg@ identifier F, G; @@ F(..., 9); *G(1, ...); @rth@ identifier F, H; @@ F(..., 9); *H(2, ...); The importan

Re: [Cocci] Increasing usage of array allocation functions with SmPL

2018-06-30 Thread SF Markus Elfring
> I've been doing some large treewide changes to the allocators, I find your update suggestion “mm: Use overflow helpers in kmalloc_array*()” interesting. https://lkml.org/lkml/2018/5/31/877 https://patchwork.kernel.org/patch/10442283/ https://lkml.kernel.org/r/<20180601004233.37822-7-keesc...@c

[Cocci] Searching for constants between shift operators with SmPL

2018-06-17 Thread SF Markus Elfring
Hello, The following script for the semantic patch language can mark a bit of source code also in a corresponding example. @display@ constant C; expression A, B; identifier X; type T; @@ T X = A << *C << B; int main(void) { unsigned int a = 2, b = 4; unsigned long c = a << 2 << b; } 1. I

[Cocci] Addition of a data type property with SmPL

2018-06-10 Thread SF Markus Elfring
Hello, I would like to try another source code transformation out with the help of the semantic patch language. @addition@ identifier var; type T; @@ T +const * var; elfring@Sonne:~/Projekte/Coccinelle/janitor> spatch --parse-cocci add_const3.cocci init_defs_builtins: /usr/local/bin/../lib/c

[Cocci] High level restriction of function calls with SmPL

2018-06-09 Thread SF Markus Elfring
Hello, I would like to try another source code transformation out with the help of the semantic patch language. The following approach can express a bit of information I became interested in. { ... when any when != action(..., input, ...) } Now I am looking for ways to restrict (or filt

[Cocci] Support for C++ delete expressions?

2018-06-03 Thread SF Markus Elfring
Hello, The information “make a small attempt to parse C++ files” is provided for the parameter “--c++” of the program “spatch”. How does the software development situation look like for the handling of “delete expressions”? http://en.cppreference.com/w/cpp/language/delete Regards, Markus

Re: [Cocci] Evolution around profiling of SmPL script execution

2018-06-01 Thread SF Markus Elfring
>How should the execution of each SmPL rule be identified there? Can the following source code adjustment help a bit besides the general possibility to clarify additional data export formats? diff --git a/cocci.ml b/cocci.ml index 64503ee9..43cfc996 100644 --- a/cocci.ml +++ b/cocci.ml @@ -1

Re: [Cocci] Evolution around profiling of SmPL script execution

2018-06-01 Thread SF Markus Elfring
> I find the corresponding description improvable for the provided data. How can it be achieved that the execution of SmPL rules will be measured also for supported scripting languages? Will it be appropriate to execute these places by the function “Common.profile_code”? Regards, Markus ___

[Cocci] Increase precision for display of SmPL script execution durations

2018-05-30 Thread SF Markus Elfring
Hello, The Coccinelle software can display profiling results for the execution of SmPL scripts. The measured durations are formatted in a way so that the information “0.000 sec” is presented for some functions so far. I guess that these data processing efforts were performed with a non-zero time v

[Cocci] Evolution around profiling of SmPL script execution

2018-05-26 Thread SF Markus Elfring
Hello, The Coccinelle software supports profiling for the execution of SmPL scripts to some degree. I find the corresponding description improvable for the provided data. 1. I would find an other separation for the available columns nicer. 2. I suggest to add a column “area” so that the measured

[Cocci] Using data from a parameter list with SmPL

2018-05-21 Thread SF Markus Elfring
Hello, A specific function can be found also by a selection on its parameter list. The semantic patch language provides a metavariable type for this purpose. I would occasionally like to create another function variant then. It should get a shorter parameter list with a few elements from the othe

Re: [Cocci] Moving a function body to an other source code place with SmPL

2018-05-14 Thread SF Markus Elfring
>> I have noticed a moment ago that a blank line is not marked by the SmPL >> asterisk operator (for a small source code example) so far. >> >> Can such whitespace characters be also preserved there anyhow? > > No. Whitespace is never preserved in metavariables. I guess that this aspect will tri

Re: [Cocci] Moving a function body to an other source code place with SmPL

2018-05-14 Thread SF Markus Elfring
>> It would be occasionally nice if an implementation of a function could be >> completely stored into a metavariable. >> Is a statement list variable appropriate for this use case? > > Yes. Thanks for your acknowledgement that it should usually work. I have noticed a moment ago that a blank li

[Cocci] Moving a function body to an other source code place with SmPL

2018-05-14 Thread SF Markus Elfring
Hello, I am curious on how good the Coccinelle software can support a specific source code transformation: It would be occasionally nice if an implementation of a function could be completely stored into a metavariable. Is a statement list variable appropriate for this use case? Can these data be

Re: [Cocci] Coccinelle 1.0.6: OpenMP #pragma directive leads to function ignore

2018-04-28 Thread SF Markus Elfring
> We can try to make the parsing of #pragmas more flexible. I am also curious on further software evolution in this area for a while. https://github.com/coccinelle/coccinelle/issues/51 Regards, Markus ___ Cocci mailing list Cocci@systeme.lip6.fr https:/

Re: [Cocci] Checking software development progress

2018-03-07 Thread SF Markus Elfring
Hello, I have noticed a moment ago that a few additional commits were published. It might be nice to test this development a bit more. I submitted the command “make distclean” and built the software by the command “./autogen && ./configure && make world” as usual. But I wonder about the message “

[Cocci] Determination for the absence of an option in a function call

2018-02-17 Thread SF Markus Elfring
Hello, I am working with the following specification in some scripts for the semantic patch language. … target = action(...); … This source code search pattern shows that a return value from a function call should be stored somewhere. The concrete call is restricted by a selection of function

Re: [Cocci] Clarification for scripted SmPL constraints

2018-02-17 Thread SF Markus Elfring
>> Which parameters should be passed to the selected function? > > You can always pass the declared metavariable. I have got special imaginations for convenient parameter passing in such an use case. > You can put a comma-separated list of inherited metavariables Do you suggest that a dependen

[Cocci] Avoiding code duplication for SmPL constraints

2018-02-17 Thread SF Markus Elfring
Hello, Constraints can be specified for metavariables of the semantic patch language. I noticed that they can trigger software maintenance challenges when bigger specifications are repeated in some SmPL rules. Now I am looking again for further possibilities to avoid corresponding code duplication

Re: [Cocci] [v2] Coccinelle: zalloc-simple: Delete function “kmem_cache_alloc” from SmPL rules

2018-01-31 Thread SF Markus Elfring
> I removed the blank line at EOF, > then applied to linux-kbuild/misc. I have taken another look at this script for the semantic patch language. I imagined that I could refactor the shown SmPL disjunctions a bit. But I noticed then that these SmPL rules contain a development mistake. The deletio

Re: [Cocci] Coccinelle: alloc_cast: Add more memory allocating functions to the list

2018-01-14 Thread SF Markus Elfring
> +// Copyright: (C) 2017 Himanshu Jha GPLv2. * Is the addition “(C)” required? * Does the year number need an update? My software development attention was caught by further implementation details in this evolving SmPL script. > +@depends on context && r1@ Will the use of a position variabl

Re: [Cocci] Coccinelle: alloc_cast: Add more memory allocating functions to the list

2018-01-14 Thread SF Markus Elfring
> Look at the script code just under the comment "For context mode" and just > under the comment "For patch mode". Both of them use m. I would like to apologise that I overlooked these places somehow. > __ are typically used in sparse annotations. Is this search pattern worth for a correspondi

Re: [Cocci] Coccinelle: alloc_cast: Add more memory allocating functions to the list

2018-01-14 Thread SF Markus Elfring
> Well, you didn't keep the semantic patch in the message. You can take another look in other information systems (if desired). https://systeme.lip6.fr/pipermail/cocci/2018-January/004848.html >> How do you think about to avoid the extra initialisation >> when only the operation mode “context” o

Re: [Cocci] Coccinelle: alloc_cast: Add more memory allocating functions to the list

2018-01-14 Thread SF Markus Elfring
>>> +@initialize:python@ >> >> The added script rule should get a condition. >> Would the specification “depends on report” be appropriate there? > > To my recollection, I wonder about this wording … > which is defined in the initialized is used in all of the cases, I imagine that you could kn

Re: [Cocci] [PATCH] Coccinelle: alloc_cast: Add more memory allocating functions to the list

2018-01-14 Thread SF Markus Elfring
My software development attention was caught by another implementation detail in this evolving SmPL script. > +@initialize:python@ The added script rule should get a condition. Would the specification “depends on report” be appropriate there? Regards, Markus ___

Re: [Cocci] Coccinelle: alloc_cast: Add more memory allocating functions to the list

2018-01-13 Thread SF Markus Elfring
> Add more memory allocating functions that are frequently used in the kernel > code to the existing list and remove the useless casts where it is > unnecessary. Thanks for your approach to extend this SmPL script. I would find the term “selection” more appropriate than the word “list” here. >

Re: [Cocci] Coccinelle: kzalloc-simple: Rename kzalloc-simple to zalloc-simple

2018-01-13 Thread SF Markus Elfring
> Rename kzalloc-simple to zalloc-simple since now the rule is not > specific to kzalloc function only, but also to many other zero memory > allocating functions specified in the rule. 1. Please add the tag “Suggested-by” to the commit description. See also: Rename the SmPL script “kzalloc-

Re: [Cocci] Automatic generation of SmPL rules by a script rule

2018-01-06 Thread SF Markus Elfring
> Well, I was thinking that you could eg make a script like: > > @script:ocaml@ > e << r.e; > @@ > > Printf.printf "@@\n"; > Printf.printf "expression f;\n"; > Printf.printf "@@\n\n"; > Printf.printf "-f(%s);\n" e I would prefer to use the available programming languages directly instead of star

Re: [Cocci] Automatic generation of SmPL rules by a script rule

2018-01-06 Thread SF Markus Elfring
> The simplest thing would be to just print the rule you want in a > python/ocaml script rule. I would like to adjust a SmPL execution environment for special use cases somehow. How would “printing” be useful here? > Some support was added at one point for generating rules based on matches > fr

[Cocci] Automatic generation of SmPL rules by a script rule

2018-01-06 Thread SF Markus Elfring
Hello, Is it possible to generate additional rules for a specific execution environment of the semantic patch language by an advanced script rule? Can a special rule generation be avoided from external software tools? Regards, Markus ___ Cocci mailing

Re: [Cocci] [v3] runchecks: Generalize make C={1, 2} to support multiple checkers

2018-01-05 Thread SF Markus Elfring
> I do feel confident that the benefits of python for this outweighs the > drawbacks > compared to my initial shell script implementation, or using perl or even C. > > Further advice on this appreciated, I got further ideas around this software situation. I am curious on how they fit to your visi

Re: [Cocci] [v3] runchecks: Generalize make C={1, 2} to support multiple checkers

2018-01-04 Thread SF Markus Elfring
> As I commented to you, some of it is a bit more in the class of good > enhancements > so whatever I haven't changed now that resonated with me, I find that some information could be better integrated already now. > I'll pick up later if the general idea is accepted. I am curious on how the

Re: [Cocci] [v3] runchecks: Generalize make C={1, 2} to support multiple checkers

2018-01-04 Thread SF Markus Elfring
> +Supported syntax of … Did you change the mind since your response “Good idea, will do” on 2017-12-23? https://github.com/torvalds/linux/commit/7bd67f980fdf33031c54955f7e04b435c267886e#r26449420 > +The ``line_len`` directive defines the upper bound of characters per line > +tolerated in this d

Re: [Cocci] [v3 0/1] Support for generalized use of make C={1, 2} via a wrapper program

2018-01-04 Thread SF Markus Elfring
Dear Knut, You chose to offer a cover letter for software adjustments which are contained in a single update step. How do you think about to integrate this information in the change log area of the other message (patch)? > Version 2 and 1 of this set and related discussion can be found here: Di

Re: [Cocci] Coccinelle: kzalloc-simple: Add more zero allocating functions

2017-12-27 Thread SF Markus Elfring
>>> The cast is useful when it is to a non-pointer type. >> >> Will it be needed then to use an other metavariable for the assignment >> target? >> >> How much would you like to distinguish if an item should handle a pointer >> (or not)? > > The compiler will complain about an assignment between

Re: [Cocci] Coccinelle: kzalloc-simple: Add more zero allocating functions

2017-12-27 Thread SF Markus Elfring
> - x = (T)kmalloc(E1,E2); > + x = (T)kzalloc(E1,E2); > > This for useless pointer cast which is done implicitily. Actually, the above rule is for the case where the cast is useful. >> >> * Have you got any special aspects in mind here? >> >> * How do you think about to re

Re: [Cocci] Coccinelle: kzalloc-simple: Add more zero allocating functions

2017-12-27 Thread SF Markus Elfring
>>> - x = (T)kmalloc(E1,E2); >>> + x = (T)kzalloc(E1,E2); >>> >>> This for useless pointer cast which is done implicitily. >> >> Actually, the above rule is for the case where the cast is useful. * Have you got any special aspects in mind here? * How do you think about to restrict it for pointer

Re: [Cocci] [PATCH] Coccinelle: kzalloc-simple: Add more zero allocating functions

2017-12-26 Thread SF Markus Elfring
> We already have zero memory allocator functions to set the memory to > 0 value instead of manually setting it using memset. Thanks for your extension of this script for the semantic patch language. Will this update suggestion get any better chances than the approach “Script to replace allocate

Re: [Cocci] Transformation challenges with SmPL around “LIST_FOR_EACH_ENTRY”

2017-12-13 Thread SF Markus Elfring
>> @adjustment@ >> expression ex; >> statement S; >> @@ >> -LIST_FOR_EACH_ENTRY >> +hlist_for_each_entry >> (..., ..., >> -ex, >> ...) >> S > > This is not completely a good idea. I tried to show another approach. > The ... in the argument list will match a sequence of things, not a single

Re: [Cocci] Transformation challenges with SmPL around “LIST_FOR_EACH_ENTRY”

2017-12-02 Thread SF Markus Elfring
>> I think I've found a bug in spatch, You showed another opportunity for further development considerations. >> or maybe I'm just using it wrong. Not really. But the specification in the shown small SmPL script could be adjusted. >> - LIST_FOR_EACH_ENTRY(c,f,g,member) S >> + hlist_for_each_

Re: [Cocci] Coccinelle: fix parallel build with CHECK=scripts/coccicheck

2017-11-23 Thread SF Markus Elfring
> The goal is that the user can easily find the stdou and stderr information > while the semantic patch is running. It matters when the tool “spatch” tries to apply its own parallelisation strategy. > This is useful for long running semantic patches to see > if things are going well or not. Ye

Re: [Cocci] [v4] Coccinelle: fix parallel build with CHECK=scripts/coccicheck

2017-11-23 Thread SF Markus Elfring
> Setting NPROC=1 is a reasonable solution; It can be sufficient for the usual purposes of the shell script “scripts/coccicheck”. > spatch does not create the subdirectory. I would like to point out that further development efforts will be needed if such a special directory handling should be

Re: [Cocci] Coccinelle: fix parallel build with CHECK=scripts/coccicheck

2017-11-14 Thread SF Markus Elfring
>>> I didn't want to use a name with the pid, so that one could easily find >>> this information while Coccinelle is running. >> >> Do you mark these data as “hidden” in the file system? > > I don't know what this means. Do you fiddle with file attributes or use a dot as the first character in th

Re: [Cocci] Coccinelle: fix parallel build with CHECK=scripts/coccicheck

2017-11-14 Thread SF Markus Elfring
> The problem on the Coccinelle side is that it uses a subdirectory with the > name of the semantic patch to store standard output and standard error for > the different threads. It is occasionally good to know such background information. > I didn't want to use a name with the pid, so that one

Re: [Cocci] Setting the section for a function with SmPL

2017-11-06 Thread SF Markus Elfring
>> @section_specification@ >> type T; >> @@ >> T rcar_pcie_enable_msi(...) >> + __attribute__((section ("my_update"))) > > I don't see any evidence that kernel developers would welcome this change > in this form. There is no welcome needed by them because the shown addition would be nice for tes

[Cocci] Setting the section for a function with SmPL

2017-11-02 Thread SF Markus Elfring
Hello, Implementations of various functions will be changed on demand. It can happen then that you would like to know if the applied changes will result also in differences for the generated code. Development tools like “size” can display some information for such a comparison. The total size di

Re: [Cocci] make install broken

2017-10-14 Thread SF Markus Elfring
>> Which information are you missing from my software surprises? > You just showed the error that looks similar to mine. I have tried another rebuild of the current software out. > You miss the part about how you configured and installed it. Would you like to take another look at affected imple

Re: [Cocci] make install broken

2017-10-13 Thread SF Markus Elfring
> Do what I did: > Describe the problem in a way that makes it easy to reproduce. I find that did this already, didn't I? Which information are you missing from my software surprises? Regards, Markus ___ Cocci mailing list Cocci@systeme.lip6.fr https:/

Re: [Cocci] make install broken

2017-10-13 Thread SF Markus Elfring
>> I find that did this already, didn't I? > No , you didn't. I can try to repeat some more technical details. >> Which information are you missing from my software surprises? > You just showed the error that looks similar to mine. Yes. - I submitted only a kind of “ping” yesterday. > You mis

Re: [Cocci] make install broken

2017-10-13 Thread SF Markus Elfring
>> Is this software development also relevant for the following error messages? >> >> elfring@Sonne:~/Projekte/Linux/next-patched> spatch >> ~/Projekte/Coccinelle/janitor/….cocci ….c >> warning: Can't find macro file: /usr/local/bin/../lib/coccinelle/standard.h >> warning: Can't find default iso f

Re: [Cocci] make install broken

2017-10-12 Thread SF Markus Elfring
> Yes, but spatch should have resolved the symlink. Anyway, I changed > the code to use realpath, which should be more reliable (the code > before only resolved symlinks on the executable file, without > considering parent directories). > > Sorry for the wrong commit! Is this software development

[Cocci] Checking for consistency of the version data by the software build system

2017-10-12 Thread SF Markus Elfring
Hello, The following command was executed on my test system again. elfring@Sonne:~/Projekte/Coccinelle/20160205> make distclean && git checkout master && git pull && ./autogen && ./configure && echo "$(./version.sh)" && grep VERSION=1 Makefile.config … 1.0.6-00335-g6e5973d4 VERSION=1.0.6-00318-

Re: [Cocci] make install broken

2017-10-06 Thread SF Markus Elfring
> The makefile issues are perhaps now resolved. How much did you check it? A few implementation details were improved. Thanks for your software corrections so far. I find that there are several aspects left over for further considerations. Examples: 1. How would you like to fix dependencies li

Re: [Cocci] Checking evolution for the build system of the Coccinelle software

2017-09-29 Thread SF Markus Elfring
> A number of recent commits have been pushed to github, It is nice to be informed about another bit of software development. > including a new make system. Now I find this kind of description too terse. > Let us know if any difficulties are encountered. * Did build targets get lost in the m

Re: [Cocci] Further improvements for safer building of the Coccinelle software

2017-09-28 Thread SF Markus Elfring
> What are you wondering about it? Was the make script changed in the way that the native executable variant will not be reinstalled with the suffix “opt” any more? https://github.com/coccinelle/coccinelle/blob/db8e301e8b28f20149d5edccc996cf6843047f7a/Makefile#L260 Do you find the following com

Re: [Cocci] Further improvements for safer building of the Coccinelle software

2017-09-28 Thread SF Markus Elfring
> A number of recent commits have been pushed to github, Thanks for your information. > including a new make system. Does this indicate a growing interest to clarify remaining (or even recurring) open issues in such a software area? > Let us know if any difficulties are encountered. I commen

Re: [Cocci] Checking statement order for patch generation with SmPL support

2017-09-08 Thread SF Markus Elfring
>> I wonder also about the information how an ordinary for loop could influence >> the shown source code analysis result for the function >> “snd_seq_queue_find_name” >> when the questionable marked statements are contained in a single if branch. >> http://elixir.free-electrons.com/linux/v4.13/sou

Re: [Cocci] Checking statement order for patch generation with SmPL support

2017-09-07 Thread SF Markus Elfring
> Thers is a control-flow path from the bottom of a loop back up to the top. I wonder also about the information how an ordinary for loop could influence the shown source code analysis result for the function “snd_seq_queue_find_name” when the questionable marked statements are contained in a sing

Re: [Cocci] Checking statement order for patch generation with SmPL support

2017-09-07 Thread SF Markus Elfring
>> But I have got difficulties to interpret it in an useful way. > > Coccinelle follows control-flow paths. This information is generally fine. > Thers is a control-flow path from the bottom of a loop back up to the top. I can not follow with my intermediate understanding to such a view at the

Re: [Cocci] Checking statement order for patch generation with SmPL support

2017-09-07 Thread SF Markus Elfring
>> Now I wonder why the software “Coccinelle 1.0.6-00242-g3f038a5d” finds >> this place relevant when the function call sequence does not fit to the order >> I tried to express for a known use case. >> I would appreciate further advice. > > Because there is a loop, This information is appropriate

[Cocci] Checking statement order for patch generation with SmPL support

2017-09-07 Thread SF Markus Elfring
Hello, I have constructed another small script for the semantic patch language. @usage@ identifier action, member, release=~"^.+free$"; expression context; @@ *release(context); <+... *action(..., (context)->member, ...) ...+> The following source code place can be found by such a simple appr

Re: [Cocci] [PATCH v4] Coccinelle: add atomic_as_refcounter script

2017-08-30 Thread SF Markus Elfring
> > Acked-by: Julia Lawall > Thank you very much Julia! I find that this acknowledgement could be presented a bit too early. > What is the correct path to merge this? It seems that you prefer to ignore some of my technical arguments (or concerns?). I hope that a safer source code search app

Re: [Cocci] cocci script to add static to const declarations ?

2017-08-30 Thread SF Markus Elfring
> Any idea on how to write a cocci script that looks for > const array declarations and adds static to them only when > all the initializers of the array are constants? Yes. - But I imagine that my ideas would not fit to the currently available Coccinelle software. How do you think about to suppor

Re: [Cocci] [PATCH v4] Coccinelle: add atomic_as_refcounter script

2017-08-30 Thread SF Markus Elfring
Dear Elena, I hoped on a more constructive feedback for remaining implementation details which should be reconsidered once more. https://systeme.lip6.fr/pipermail/cocci/2017-August/004341.html * Will any more revisions be needed for your evolving script until special development concerns will b

Re: [Cocci] [PATCH v4] provide rule for finding refcounters

2017-08-30 Thread SF Markus Elfring
> changes in v4: > … Do you find this cover letter still relevant for the clarification of remaining open issues in a single SmPL script? Regards, Markus ___ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] Addition of support for conjunctions on types

2017-08-28 Thread SF Markus Elfring
>> I am looking for descriptions about circumstances under which the >> metavariable combination >> will be useful by the mentioned SmPL conjunctions. > > I still don't understand the question. It seems that I have got a few understanding difficulties with the added functionality. > Another e

Re: [Cocci] Addition of support for conjunctions on types

2017-08-28 Thread SF Markus Elfring
> I have no idea what information is wanted. I am looking for descriptions about circumstances under which the metavariable combination will be useful by the mentioned SmPL conjunctions. Regards, Markus ___ Cocci mailing list Cocci@systeme.lip6.fr http

Re: [Cocci] Addition of support for conjunctions on types

2017-08-28 Thread SF Markus Elfring
>> I would like to know a bit more for the application of such a metavariable >> combination. I would appreciate another feedback for this aspect. >> Unfortunately, I get the information “… Fatal error occurred, no output PDF >> file produced! …” from data processing by the command “make docs”.

Re: [Cocci] Addition of support for conjunctions on types

2017-08-28 Thread SF Markus Elfring
> @@ > type t; > identifier i; > @@ > > ( > struct i > & > t > ) > > will now bind both i and t appropriately. I would like to know a bit more for the application of such a metavariable combination. I hoped also to read something about it in the current manual. Unfortunately, I get the informati

Re: [Cocci] Addition of support for variable attributes

2017-08-28 Thread SF Markus Elfring
> It is now (github) possible to match and transform a single such attribute > when it comes after the name of a variable in a variable declaration. This is a nice extension for your software. How does this information fit to the wording in the manual? https://github.com/coccinelle/coccinelle/blo

Re: [Cocci] Matching function prototypes and casts

2017-08-25 Thread SF Markus Elfring
>> ( >> *setup_timer(&E->_timer@tl, \((_func)\| \) \(&\| \) _callback, \((_data)\| >> \) E); >> | >> *E->_timer@tl.function = \((_func)\| \) \(&\| \) _callback; >> ) > > No, it doesn't work, because \( \| \) matches an expression and there is > no empty expression. Will the Coccinelle software b

Re: [Cocci] Matching function prototypes and casts

2017-08-25 Thread SF Markus Elfring
> I had --no-includes in my .cocci. Would you like to transform also any header files by the mentioned approach? > More insane corner cases: Are you looking for further clarification there? Regards, Markus ___ Cocci mailing list Cocci@systeme.lip6.fr

Re: [Cocci] Matching function prototypes and casts

2017-08-25 Thread SF Markus Elfring
>> You try to search for variations of a function call and an assignment to >> a data structure member. It seems that they differ then by the usage of a >> cast >> and the operator “&”. >> How do you think about to express such search criteria in a succinct way with >> the help of the semantic pat

Re: [Cocci] Matching function prototypes and casts

2017-08-25 Thread SF Markus Elfring
> ( > -setup_timer(&_E->_timer@_e, _callback, _E); > | … > -_E->_timer@_e.function = (_cast_func)&_callback; > ) You try to search for variations of a function call and an assignment to a data structure member. It seems that they differ then by the usage of a cast and the operator “&”. How do you

Re: [Cocci] parsing of C code

2017-08-24 Thread SF Markus Elfring
> More importantly; does Julia like red jelly beans more than blue jelly beans? Would you like to discuss favourite sweets more than to clarify further improvements in parsing technology also for application together with the Coccinelle software? ;-) Regards, Markus

Re: [Cocci] parsing of C code

2017-08-24 Thread SF Markus Elfring
> Parsing of foo fails due to the attribute __xxx(yyy) that Coccinelle is > not able to cope with. * Do you find information relevant from answers to a question like “Context-free grammars versus context-sensitive grammars?”? https://stackoverflow.com/questions/8236422/context-free-grammars-v

Re: [Cocci] parsing of C code

2017-08-24 Thread SF Markus Elfring
> Parsing of foo fails due to the attribute __xxx(yyy) that Coccinelle is > not able to cope with. Why does the parsing software struggle with such input data so far? > Coccinele hopes that expanding macros will solve the problem. Why do you need to “hope” something if the software could be des

Re: [Cocci] parsing of C code

2017-08-24 Thread SF Markus Elfring
> Actually, I noticed that unfolding macros can sometimes hurt more than it > helps. Would you like to discuss (or explain) involved implementation details and configuration parameters any more? Regards, Markus ___ Cocci mailing list Cocci@systeme.lip6

Re: [Cocci] parsing of C code

2017-08-24 Thread SF Markus Elfring
>> If it's yacc based you can recover where ever you like. Knowing how to >> do it is something of a black art. > Well, ocamlyacc, to be precise. Can the software “Menhir” help any more for the needed data processing? http://gallium.inria.fr/%7Efpottier/menhir/ Regards, Markus _

Re: [Cocci] parsing of C code

2017-08-24 Thread SF Markus Elfring
> I have tried to improve the parsing of C code recently. This information is useful. > 1. More aggressive inclusion of header files, Why do you need to become “aggressive” there when the corresponding data processing should be just correct? > combined with caching of header files. How do y

Re: [Cocci] parsing of C code

2017-08-24 Thread SF Markus Elfring
> At least for the Linux kernel, you can't just run one make and get all the > files to be compiled. Some files are indeed very hard to compile. How do you think about to point any specific source code examples out which you find a bit too challenging so far? Regards, Markus

Re: [Cocci] Comparing statement lists with SmPL

2017-08-24 Thread SF Markus Elfring
> If you like the results from the second case, what more do you want? I would like to achieve somehow that the number of presented “false positives” will become so low so that similar (and extended) SmPL scripts can be used for more automatic source code transformations with higher confidence. *

Re: [Cocci] Comparing statement lists with SmPL

2017-08-23 Thread SF Markus Elfring
>> How should the source code search be improved further here? > > If you like the results from the second case, what more do you want? * There are also several questionable transformation suggestions generated besides the usable ones. * Will answers belong also to the topic “Get the non-optio

Re: [Cocci] Comparing statement lists with SmPL

2017-08-23 Thread SF Markus Elfring
> You would need when any on the ... Otherwise, it will not match anything > (perhaps declarations). The s1 after is precludes matching any statement. > Likewise in the next if. The suggested variant does still not work in the way I would expect it. @duplicated_code@ identifier work; statement s

Re: [Cocci] Comparing statement lists with SmPL

2017-08-23 Thread SF Markus Elfring
> I have tried another variant out for a source code analysis. Does the following SmPL script variant make sense? @duplicated_code@ identifier work; statement s1, s2; type T; @@ T work(...) { ... when any *if ((...) < 0) *{ ... * s1 * s2 *} <+... *if ((...) < 0) *{ ... * s1 *

Re: [Cocci] Comparing statement lists with SmPL

2017-08-22 Thread SF Markus Elfring
>>> The pattern matched in two different functions? >> >> Please look once more. >> >> Yes. - This is one of the reasons why I ask here again. >> >> I would like to choose if a code analysis should happen only within a single >> function >> or on interesting parts from the complete source file. >

Re: [Cocci] Comparing statement lists with SmPL

2017-08-22 Thread SF Markus Elfring
>> How do the presented functions “usb6fire_fw_ezusb_upload” and >> “usb6fire_fw_fpga_upload” >> fit to this information? > > The pattern matched in two different functions? Please look once more. Yes. - This is one of the reasons why I ask here again. I would like to choose if a code analysis

Re: [Cocci] Comparing statement lists with SmPL

2017-08-22 Thread SF Markus Elfring
>> * A test result was shown from two function implementations. >> It can be nice to compare several functions. >> Is it also possible that the comparison will be only performed within >> the same function bodies? > > If you make a single rule then it will only applied within individual > f

Re: [Cocci] Comparing statement lists with SmPL

2017-08-22 Thread SF Markus Elfring
>> How would you like to treat variations in such log messages? > > They look fine as they are. I have got other development opinions there depending on the preferred design goals. * The mentioned small SmPL script can also help to find special differences. * These log statements are similar (

Re: [Cocci] Comparing statement lists with SmPL

2017-08-22 Thread SF Markus Elfring
>> * Are there further development challenges to consider for the safe >> identification >> of unique statements by metavariables? > > If you want to ensure that two metavariables match things > in different places, then put a position variable on each match > and use apython rule afterwards to

Re: [Cocci] Checking evaluation of another script with SmPL constraints

2017-08-19 Thread SF Markus Elfring
> Now I wonder about this software situation. I can reduce my evolving SmPL script for another test. * Using only simple strings for the constraints according to the two known function names in the implementation which should be found. http://elixir.free-electrons.com/linux/v4.12.8/source/fs

[Cocci] Checking evaluation of a regular expression for a SmPL constraint

2017-08-19 Thread SF Markus Elfring
Hello, Today I published the update suggestion “[PATCH 1/3] ecryptfs: Delete 21 error messages for a failed memory allocation”. https://patchwork.kernel.org/patch/9910539/ https://lkml.kernel.org/r/<1dcce3db-c162-c6bc-d1a8-bcf427248...@users.sourceforge.net> I noticed during the preparation of th

Re: [Cocci] Improving size determinations with SmPL

2017-08-18 Thread SF Markus Elfring
> Here I have the c code, You have also access to the referenced source files for this Linux software module. > but not the semantic patch. I find this kind of feedback surprising. We discussed it a bit yesterday so that this SmPL script was stored also in the mailing list archive. https://sy

Re: [Cocci] Improving size determinations with SmPL

2017-08-18 Thread SF Markus Elfring
> The suggested script variant seems to work finally. I have tried it out once more with the following command. elfring@Sonne:~/Projekte/Linux/next-patched> spatch.opt --timeout 67 -j 4 --in-place ~/Projekte/Coccinelle/janitor/safer_size_determination2.cocci fs/jfs … EXN: Common.TimeoutNote: pro

<    5   6   7   8   9   10   11   12   13   14   >