>>> 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
> - 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
>>> - 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
> 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
>> @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
>> 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
>> +
> 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
>>> 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
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
>> 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
> 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
>> 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
>> 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
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
> 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
>> 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.
>>
> 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
>> 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
>> 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
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
> > 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
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
> 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
>> 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
> 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
>> 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
> @@
> 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
> 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?
>> (
>> *setup_timer(>_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
> 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
>> 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
> (
> -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
> 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
> 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?”?
>> 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
> 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
> 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
> 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.
>> 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
> 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
> 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
*
>>> 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.
>
>> 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
>> * 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
>
>> 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
>> * 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
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
> 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:
>> * 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
>> elfring@Sonne:~/Projekte/Linux/next-patched> git checkout next-20170803 &&
>> spatch.opt ~/Projekte/Coccinelle/janitor/show_same_statements3.cocci
>> fs/ubifs/lpt.c
>> …
>> @@ -1974,10 +1974,6 @@ again:
>> int ret, lnum = lprops->lnum;
>>
>> ret = scan_cb(c, lprops,
>>> Can the search for duplicated source code be improved by the means of the
>>> semantic patch language?
>>
>> For two statements at least you could do:
>
> An other SmPL script variant can work to some degree.
How do you think about the relevance of the SmPL construct “<+... ...+>”
for this
>> ... when any should be <...
>
> I have told you exactly what to do here.
You are right in the sense that I misinterpreted your change suggestion.
> The line above currently contains ... when any. It (and only it) should be
> completely removed and changed to <...
But I find it
>>> ... when any should be ...>
>>
>> I am unsure if I interpret your suggestion correctly.
>
> No. Go read the original message again. It says exactly what to do and
> where it should be done.
Your hint might be nice.
> Eg, my message has two comments, but you have made three changes, which
> ... when any should be ...>
I am unsure if I interpret your suggestion correctly.
@replacement@
identifier action, var, work;
type T, X;
@@
T work(...)
{
<... ... when any ...>
X* var;
<... ... when any ...>
var = action(...,
sizeof(
-X
+
Hello,
I have constructed the following small script for another application of the
semantic patch language.
@replacement@
identifier action, var, work;
type T, X;
@@
T work(...)
{
... when any
X* var;
... when any
var = action(...,
sizeof(
-X
+
Dear Elena,
Why do you insist to use the variables “fname2” till “fname6” in
this evolving SmPL script (instead of merging them into a single one
with a special constraint)?
How do you think about to omit the cover letter for the addition
of such a script (when the change log can be integrated
>> Can the search for duplicated source code be improved by the means of the
>> semantic patch language?
>
> For two statements at least you could do:
An other SmPL script variant can work to some degree.
@duplicated_code@
identifier work;
statement s1, s2;
type T;
@@
T work(...)
{
... when
> Unfortunately, the software version “1.0.6-00186-g0acd38ee” does not like this
> SmPL specification.
I overlooked to add parentheses in my evolving SmPL script.
@duplicated_code@
identifier work;
statement s1, s2;
statement list sl;
type T;
@@
T work(...)
{
... when any
(
*if ((...) < 0) {
>> Can the search for duplicated source code be improved by the means of the
>> semantic patch language?
>
> For two statements at least you could do:
>
> (
> {
> s1
> s2
> ...
> }
> &
> {
> sl
> }
> )
I constructed another SmPL script based on this suggestion as follows.
@duplicated_code@
>> Now I am looking for a way to express the constraint that the statement list
>> metavariable should match only source code with two statements at least.
>> Can the search for duplicated source code be improved by the means of the
>> semantic patch language?
>
> For two statements at least you
> The source code analysis results look promising by this command.
I have just noticed that an other source file points details out for further
development considerations around the mentioned functionality from the
Coccinelle software.
elfring@Sonne:~/Projekte/Linux/next-patched> git checkout
>> * How can be determined how many code is equivalent between two statement
>> list variables?
>
> I guess you can make special cases, for one statement, two statements, etc.
I guess that we would like to avoid such an approach for some use cases.
I hope that there are safer programming
>> Is this programming interface usable to determine if any code could be
>> combined
>> to some degree?
>
> I don't really understand the questions.
I try again to describe the use case I became interested in a bit more.
> Statement list metavariables can be used once they are bound like any
Hello,
The Coccinelle software supports metavariables with the type “statement list”.
Can statement lists be compared if they refer to the same source code
structures?
Is this programming interface usable to determine if any code could be combined
to some degree?
Regards,
Markus
> Elena, please don't follow Markus's suggestion.
I suggest to consider additional software development possibilities.
We have got recurring different opinions around the application of advanced
regular expressions.
> Coccinelle doesn't interpret regular expressions when selecting code to work
Dear Elena,
Would you like to take another look at my development suggestion for your
approach?
https://systeme.lip6.fr/pipermail/cocci/2017-August/004300.html
How do you think about to refactor another rule like the following?
@r3 exists@
expression E;
identifier
Dear Elena,
I have also taken another look at your script.
The SmPL rule “r1” specifies six metavariables for identifiers. It seems that
the names “fname3” till “fname6” do not care for different function parameters
in the SmPL disjunction at the end.
How do you think about to reduce this
> So I get the impression that an other build approach will be safer there.
> How do you think about to add a dependency specification so that interface
> descriptions will be always compiled before the corresponding OCaml code?
I showed change possibilities which can improve the software
> Why do I get such an error message for a parallel software build attempt
> when the specified dependencies worked as expected for the non-parallel
> build try before?
How do you think about the corresponding update suggestion
“Improve some dependency specifications in make rules”?
> The OCaml makefile specifies an order in which the files should be
> compiled in the project. If you are sidestepping that ordering, then you
> are not doing things in the intended manner.
I hope that some details were clarified to some degree in the meantime.
> There is only an intent to
> OK, I don't undertand what command you are doing to get the problem,
Did we achieve a better common understanding in the meantime?
> so I can't reproduce it, so I can't determine whether it is a real issue.
* Are you really keen to achieve this also in your own test environments?
* How much
> The command “ocamldep *.mli *.ml > .depend” was performed for
> relevant subdirectories.
> Unfortunately, this approach seems to be insufficient for the desired
> safe integration of dependency information so far.
I have got another idea. The adjustment results were more promising for my
build
>> Can you get the impression from the mentioned error message examples
>> that the desired software build prerequisites failed anyhow?
>
> Something fails in your situation, but without knowing the arguments to
> the compiler, I don't know what.
You could know also from the reduced information.
> The command “ocamldep *.mli *.ml > .depend” was performed for
> relevant subdirectories.
> Unfortunately, this approach seems to be insufficient for the desired
> safe integration of dependency information so far.
How do you think about to work any more with dedicated files
for each source file
>> I showed how I could stumble on open issues.
>
> No you didn't.
I try then once more to help you to interpret the mentioned
error message examples.
The command “ocamldep *.mli *.ml > .depend” was performed for
relevant subdirectories.
Unfortunately, this approach seems to be insufficient
>> I am curious on how a dependency for a software interface like
>> “Visitor_ast0_types”
>> should be expressed for so many source files in a consistent way.
>
> What problem are you trying to solve?
I would like to achieve something more for the topics which were also registered
in the issue
> If you have changed things, then perhaps you have caused the problem?
I have found an approach for the adjustment of affected build scripts
where I can improve the involved dependency specifications in a few
subdirectories on my own to some degree.
But I guess that a directory like
> If you have changed things, then perhaps you have caused the problem?
This is also another possibility in principle.
It seems that I wonder again why some source files should be compiled without
interface description files there.
An other script variant showed the following result.
> So I get the impression that an other build approach will be safer there.
> How do you think about to add a dependency specification so that interface
> descriptions will be always compiled before the corresponding OCaml code?
Hello,
I have achieved another bit of progress with my attempt to
Hello,
I have achieved a bit of progress with one experiment for build script
adjustments.
I would like to try further changes out. Unfortunately, I stumbled on an error
message like the following from the program “GNU Make 4.2.1-1.7” then.
…
/usr/bin/ocamlopt.opt …
File "cocci.ml", line 1:
>> Can it become safer and more convenient to handle assignments here?
>
> I have no idea what you are asking for.
I wonder about such a kind of feedback.
> In any case, an expression metavariable already matches a variable.
This information can be appropriate in some source code situations.
> var = action(...);
This specification looks also simple for the semantic patch language
at first glance.
I tried to express that a specific value is assigned to something.
But this “something” could be a different item depending on the position
in the source code.
1. Variable
2. Expression
3.
> var = action(...);
> if (failed(var))
This SmPL specification contains a few further software development challenges.
1. It could be taken into account that a function call and a corresponding check
for the return value are not directly next to each other.
A SmPL ellipsis could be
> How can the Coccinelle software help any more in such an use case?
This small SmPL script example demonstrates two special selections of functions
by their name. They belong to separate categories then.
* The primary actions should usually provide a return value somehow.
* A call of a
I would like to clarify the possibilities for corresponding software extensions
a bit more.
The Coccinelle software provides also the search operator “question mark” which
denotes code on a specific line as optional.
Hello,
I would like to check the implementation of exception handling in various
source files. The following script for the semantic patch language tries to
express a few possibilities for such a source code search pattern.
@show_special_reactions@
expression error_code, var;
identifier action
>> I find it just strange that extra parentheses are needed in such an use case
>> at the moment.
>
> ... is used in a number of contexts in SmPL, and sometimes its use has to
> be restricted to avoid parsing ambiguities.
I tried to use extra parentheses for other source code search patterns.
I
>>> Maybe put parentheses around the second argument. An isomorphism will
>>> drop them and you will avoid whatever parsing issue is being encountered.
>>
>> I do not observe a desired improvement after such a SmPL code adjustment.
>
> Your change is not what I suggested either. The second
Hello,
I would like to check also the application of elements which are used together
with binary operators like the following.
@find@
expression target;
identifier action;
@@
target = action(...,
...
*| __GFP_NOFAIL
| ...,
> This script finds instances of allocate and memset which can be
> replaced with a direct call to zalloc equivalent of a function.
What is the software development status for this SmPL script in comparison
to an other directory for source code transformations?
> The comm_assoc isomorphism allows A || ... to match any disjunction where
> A appears at the top level, not just in the far left position.
Thanks for your explanation.
Are there further software development challenges to consider around the
handling
of items like position variables and “mixed
> elfring@Sonne:~/Projekte/Coccinelle/janitor> spatch.opt
> replace_kcalloc_by_memdup_user-draft1.cocci ../Probe/user_sdma-excerpt1.c
> …
> refactoring: position variables or mixed modifs interfere with comm_assoc iso
> bool (bool !to
> >>> IS_ERR(to)
> || ...)
> …
Would you like to explain
Hello,
I came along another function implementation where I got the impression that
the function “memdup_user” could also be used there in a way which is similar
to an existing source code transformation approach by a small script for
the semantic patch language.
SmPL script:
Hello,
I have tried the following small script out for the semantic patch language.
@show_assignments@
expression target;
identifier code =~ "^E[A-Z]+$";
statement is, es;
@@
*target = -(code);
if (...)
is
else
es
elfring@Sonne:~/Projekte/Linux/next-patched> spatch.opt -timeout 23
> Is there a clever way of conditionally making this change?
The answer depends on your desire how “clever” (or sophisticated) an other
approach
should become.
You could try to work with more disjunctions and rules in the semantic patch
language.
This transformation might trigger a few target
>> need to put another copy of that at the end of the rule with ? in front
>> of it. So that it stops when it comes to that again.
>
> And now it's working just fine.
I became also curious on how the discussed source code transformation can
really work. I imagine that there are still some
> Why were you looking for such functions in the first place?
These functions provide various return values. I am curious on how often
the returned values will actually be checked and used (or not).
> If you want non-static non-void functions and you find them,
> then what is the issue?
NetBSD
Hello,
I tried the Coccinelle software out for another source code analysis approach
on source files from NetBSD 7.0.2.
A small SmPL script worked mostly so good that 136978 non-static function
implementations were finally found with a non-void return type there.
* Can such an analysis result
>> Can you generally clarify current consequences from usage of a SmPL rule
>> “initialize:…”
>> together with the parameter “--jobs” for the program “spatch”?
>
> It should happen only once.
Thanks for this information.
I would like to know if the script initialisation should happen for each
> Without having the semantic patch and the .c file, ideally with both
> cut down to a minimal version that shows the problem,
> I can't answer this question.
Can you generally clarify current consequences from usage of a SmPL rule
“initialize:…”
together with the parameter “--jobs” for the
901 - 1000 of 1468 matches
Mail list logo
