> This patchset adds a feature to enable Coccinelle
> to only check all those files in a directory which were
> modified. It parses all the files obtained from the
> output of "git diff" and checks them against the specified
> cocci script.
>
> An example for passing the "use-patchdiff" option is:
> v5: print a message with the new function name, as suggested by …
Thanks for another small adjustment.
Thus I find an other version number consistent in the patch subject.
Do you care to influence the run time characteristics a bit more
for such a script variant by reducing the number of SmPL
…
> +msg = "WARNING: opportunity for pm_runtime_get_sync"
> +coccilib.org.print_todo(j0[0], msg)
…
Do you find the following message variant more helpful?
+coccilib.org.print_todo(j0[0],
+"WARNING: opportunity for replacing
pm_runtime_get_sync() by
>… keeps a reference count on failure, …
Would you get into the mood to perform a systematic source code search
for similar function implementations according to resource clean-up?
> v2: better keyword
How do you think about to add the information “wrapper functions” here?
…
> +@r0 depends
…
> +// Keywords: kwd
…
Will any information become more helpful and succinct for such a SmPL script
variant?
Regards,
Markus
___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci
> I'm asking you to put the regexp in a python function.
Will it become easier and more convenient to search for string literals
(and their exclusion according to the discussed transformation approach)?
@initialize:python@
@@
def occurs(x):
return '"' in x
@display@
identifier i =~
>> I hoped that the specified constraint for the metavariable “e” would mean
>> that expressions which contain a double quotation character should be
>> excluded
>> for my source code analysis approach.
>> Would you like to check the observed software functionality once more?
>
> There is perhaps
>> I would like to avoid the repetition of parsing efforts as much as possible.
>> Under which circumstances can replacement lists be taken better into account?
>
> Why does my suggestion involve a repetition of parsing effort?
The selection of the applied programming interfaces has got
>mac = of_get_mac_address(np);
>if (!IS_ERR(mac))
> ether_addr_copy(ndev->dev_addr, mac);
>
> This would need to be changed to:
>
>of_get_mac_address(np, ndev->dev_addr);
Can such a function call variant fail?
How do you think about take any special return values into account?
Hello,
Will the software development interests ever evolve in ways so that #define
directives
can be replaced with the help of the semantic patch language for special source
code
analysis and transformation approaches?
https://github.com/coccinelle/coccinelle/issues/139
Regards,
Markus
Hello,
The Coccinelle software can search for header files in addition to source files
if the option “--include-headers” was specified.
https://github.com/coccinelle/coccinelle/blob/287374196da8c7cfd169e721a2d23f1e462422f1/docs/manual/spatch_options.tex#L43
How can it be achieved that only
> A new version 1.1.0 has been released.
Thanks.
I have dared to activate also a current OCaml version by the command
“opam switch create 4.12.0”.
I have tried to rebuild your software accordingly.
elfring@Sonne:~/Projekte/Coccinelle/20160205> make distclean && git checkout
master && git pull
> +- tmp = a;
> +- a = b;
> +- b = tmp;
> ++ swap(a, b);
How do you think about to use the following SmPL code variant?
* Omission of a few leading space characters
* Keeping a semicolon unmodified in a line
+-tmp = a;
+-a = b;
+-b = tmp
++swap(a, b)
+;
Regards,
Markus
…
> +++ b/scripts/coccicheck
…
> @@ -186,14 +185,11 @@ coccinelle () {
…
> +if [ -n "$REQ" ] && ! { echo "$REQ"; echo "$SPATCH_VERSION"; } | sort
> -CV ; then
Would it make sense to use an other command control operator?
+if [ -n "$REQ" ] && ! { echo "$REQ" && echo "$SPATCH_VERSION"; }
> Why do you want to remove the semicolon?
I have shown a transformation example where a function parameter should be
replaced
by a previous function call.
Thus a semicolon should be intentionally be deleted.
> If you want to find the call somewhere in the next statement, you can say
>
> (
> S
>> I have shown a transformation example where a function parameter should be
>> replaced
>> by a previous function call.
>> Thus a semicolon should be intentionally be deleted.
>
> That makes no sense.
This transformation part is working as expected (under constraints) already.
> You can't
>>> You can't have an expression directly following a statement.
>>> Only statements follow other statements.
>>
>> This information is reasonable.
>>
>> Does the Coccinelle software insist on the specification of another semicolon
>> in the SmPL script for the identification of an adjustable
Hello,
The following small SmPL script gets successfully parsed by the Coccinelle
software.
@Replacement@
expression call, input, target;
identifier gs;
@@
-\( g_string_assign@gs \| g_string_append@gs \) (target, input);
call (
- target
+ gs (target, input)
);
But if I would
> Changes in v2(as suggested by Markus):
Thanks you picked a few suggestions up.
I would appreciate further constructive clarifications.
…
> +++ b/scripts/coccinelle/locks/balancedlock.cocci
…
> +//# False positives may be generated due to locks released within a nested
> +//# function call
> If you want to ensure that your generated code has such properties,
> you can use the argument --smpl-spacing.
It is nice that code additions can be influenced by such a parameter.
> If you want something more, you are welcome to implement it.
I imagine that adjustments for matched
> If you want to ensure that your generated code has such properties, you
> can use the argument --smpl-spacing.
Can there be a need for a related run time parameter for the handling
of line breaks?
Regards,
Markus
___
Cocci mailing list
Hello,
The coding style specification for C programs in GNOME contains also
the following information.
https://developer.gnome.org/programming-guidelines/stable/c-coding-style.html.en#whitespace
“…
Always put a space before an opening parenthesis but never after:
…”
How good can the semantic
>> … git grep -l -w \( -e for_each_node_by_type … -e
>> for_each_node_with_property \) -- '*.c'
>>
>>
>> How do you think about to omit these parentheses here?
>
> Does it make a difference?
I find that it can be nicer to avoid the passing of unnecessary characters.
* The compilation of the
> Will any adjustments become relevant then accordingly?
I have found out that the function “interpret” (OCaml code) constructs a command
and executes it.
https://github.com/coccinelle/coccinelle/blob/3c01dc1696dc5ccfb319673f205e491b572ee0be/parsing_cocci/git_grep.ml#L9
I have tried a
>> This analysis result indicates a clear ranking for such function calls.
>> Thus reorder the SmPL disjunction items according to their usage incidence.
>
> Did you actually test this before and after the change and see a
> difference in performance?
Would you become interested to configure a
>> Would you become interested to configure a representative test environment
>> for safe comparisons of corresponding run time characteristics
>> of the affected software?
>
> In what sense could the comparison possibly be unsafe?
* Our test systems are obviously different.
Thus concerns can
From: Markus Elfring
Date: Sun, 25 Oct 2020 14:10:58 +0100
A disjunction is applied by this script for the semantic patch language.
This construct uses short-circuit evaluation. It has got the consequence
that the last element of the specified condition will only be checked
if all previous parts
> In the patch case, the user and system time are essentially identical.
> In the context case, the difference in user time is 2 seconds out of 9.5
> minutes, 0.3%.
This was just a single test run example.
> In the patch case, the real time is a bit slower.
I wonder about such an
From: Markus Elfring
Date: Sun, 25 Oct 2020 18:54:36 +0100
A disjunction is applied by this script for the semantic patch language.
This construct uses short-circuit evaluation. It has got the consequence
that the last element of the specified condition will only be checked
if all previous parts
I'd like to add a statement after another within a preprocessor expression,
How do you think about to refer to a “#define directive”?
but spatch adds the line without an escape (backslash).
I imagine that we stumble on another target conflict here.
> > Can such facts influence the specification of efficient SmPL disjunctions
> > another bit?
>
> On my machine, putting the three functions that you have foudn to be the
> most frequent at the end of each disjunction has no impact on the performance.
I propose to reconsider this view.
> So
> …
> > +E = \(kmalloc\|kzalloc\|krealloc\|kcalloc\|
> > + kmalloc_node\|kzalloc_node\|kmalloc_array\|
> > + kmalloc_array_node\|kcalloc_node\)(...)@kok
> …
>
> How do you think about the possibility for any adjustments according to the
> order
> of the mentioned function
> Would you like to look for software configuration alternatives for better
> parallel data processing?
I would like to share another source code analysis approach.
I hope that this contribution can trigger further helpful software development
ideas.
@initialize:python@
@@
import sys
def
> …
> > +(
> > +for_each_node_by_name(n,e1) S
> > +|
> …
> > +|
> > +for_each_node_with_property(n,e1) S
> > +)
> …
>
>
> Do you indicate any occurrence frequencies or probabilities for the mentioned
> macro calls
> by the ordering in this disjunction for the semantic patch language?
I would
> > How do you think about the possibility for any adjustments according to the
> > order
> > of the mentioned function names in proposed disjunctions for the semantic
> > patch language?
>
> Please think about this for 5 seconds. Maybe there are 2000 calls to
> these allocation functions, and
…
> +E = \(kmalloc\|kzalloc\|krealloc\|kcalloc\|
> + kmalloc_node\|kzalloc_node\|kmalloc_array\|
> + kmalloc_array_node\|kcalloc_node\)(...)@kok
…
How do you think about the possibility for any adjustments according to the
order
of the mentioned function names in proposed
Hello,
The manual for the semantic patch language mentions the grammar item “rulekind”.
https://github.com/coccinelle/coccinelle/blob/730dbb034559b3e549ec0b2973cd0400a3fa072f/docs/manual/cocci_syntax.tex#L116
I would appreciate further information for the safe application of such a
technical
> +@ruletwo depends on patch && !context && !org && !report@
How do you think about to combine code from two SmPL rules
by using another SmPL disjunction like the following?
@addition_rule depends on patch && !context && !org && !report@
local idexpression r.n;
expression e,e1;
expression list
From: Markus Elfring
Date: Wed, 23 Sep 2020 18:30:25 +0200
A wrapper function is available since the commit
7723f4c5ecdb8d832f049f8483beb0d1081cedf6
("driver core: platform: Add an error message to platform_get_irq*()").
Provide design options for the adjustment of affected s
> +// Confidence: High
Will an addition like the following be helpful?
+// Options: --no-includes --include-headers
> +@r@
> +local idexpression n;
> +expression e1,e2;
> +iterator name for_each_node_by_name, for_each_node_by_type,
> +for_each_compatible_node, for_each_matching_node,
>
> I have noticed the update suggestion “USB: quirks: simplify quirk handling”.
> https://lore.kernel.org/linux-usb/20200921113039.ga19...@duo.ucw.cz/
> https://lore.kernel.org/patchwork/patch/1308991/
I would like to point out that an acceptable patch can be generated for
the implementation of
Hello,
I have noticed the update suggestion “USB: quirks: simplify quirk handling”.
https://lore.kernel.org/linux-usb/20200921113039.ga19...@duo.ucw.cz/
https://lore.kernel.org/patchwork/patch/1308991/
Thus I converted a patch hunk into the following script variant for
the semantic patch
Hello,
I have tried another tiny script variant out for the semantic patch language
(according to the software combination “Coccinelle 1.0.8-00177-g28737419”).
@find@
identifier i;
type t;
@@
t i(...)
{ ... }
@find_static@
identifier find.i;
type find.t;
@@
static t i(...)
{ ... }
@display
…
> +++ b/scripts/coccicheck
> @@ -126,8 +126,14 @@ run_cmd_parmap() {
> if [ $VERBOSE -ne 0 ] ; then
> echo "Running ($NPROC in parallel): $@"
> fi
> - echo $@ >>$DEBUG_FILE
> - $@ 2>>$DEBUG_FILE
> + if [ "$DEBUG_FILE" != "/dev/null" -a "$DEBUG_FILE" != "" ];
> Implement a name cache and includes dependency graph to optimize
> performance for recursive parsing of header files.
Can such information trigger any more evolution besides the contributed
OCaml source code?
> The names of the above are stored in a "name cache", i.e. a hashtable
> to map
> This patch series aims to optimize performance for recursively parsing
> header files in Coccinelle.
I am curious how you got encouraged to pick such a software development
challenge up.
> it would take close to 7 hours to complete.
This is unfortunate.
How do you think about to offer any
> Modify coccicheck to use the shift command only when
> number of shell arguments is not zero.
I suggest to add the tag “Fixes” to the commit message.
> Changes in V2:
> - Fix spelling errors as suggested by Markus Elfring
Would you like to adjust the last word in the pr
From: Markus Elfring
Date: Mon, 7 Sep 2020 18:38:04 +0200
Another wrapper function is available since the commit
890cc39a879906b63912482dfc41944579df2dc6
("drivers: provide devm_platform_get_and_ioremap_resource()").
Provide safe design options for the adjustment of affected s
>> +@display depends on context@
>> +expression base, device1, device2, index, private, resource;
>> +@@
>> +(
>> +*resource = platform_get_resource(device1, IORESOURCE_MEM, index);
>> + base =
>> +* devm_ioremap_resource
>> + (>dev, resource);
>
> Why do you
From: Markus Elfring
Date: Mon, 7 Sep 2020 13:14:44 +0200
Another wrapper function is available since the commit
890cc39a879906b63912482dfc41944579df2dc6
("drivers: provide devm_platform_get_and_ioremap_resource()").
Provide design options for the adjustment of affected source code
by
> Extend the list of free functions with kvfree(), kvfree_sensitive(),
> vfree().
How do you think about further software extensions for this source code search
pattern?
Another example for a corresponding advanced data processing approach:
> Is it me not understanding cocci grammar again?
You are also struggling with expressing your data processing needs
by the means of the semantic patch language.
You would like to rename three parameters for selected functions.
I imagine that an other transformation specification will be more
> Suggest flex_array_size() wrapper to compute the size of a
> flexible array member in a structure. The macro additionally
> checks for integer overflows.
Can the following script variant for the semantic patch language help
to clarify any software development ideas and remaining open issues?
>> Will this information trigger further consequences for the clarification
>> of the topic “[RFC PATCH] coccinelle: api: add flex_array_size.cocci script”?
>> https://lore.kernel.org/cocci/20200828163134.496386-1-efre...@linux.com/
>>
>> @replacement@
>> identifier array, instance, size;
>> type T;
>> @@
>> (
>> -sizeof(T)
>> |
>> -sizeof(*instance->array)
>> )
>> *
>> +flex_array_size(instance, array,
>> instance->size
>> + )
>
> This semantic patch will fail if the sizeof(T) option is matched,
Hello,
The following small script variant for the semantic patch language gets accepted
according to the software combination “Coccinelle 1.0.8-00159-g730dbb03”.
@replacement@
identifier array, instance, size;
type T;
@@
(
-sizeof(T)
|
-sizeof(*instance->array)
)
*
+flex_array_size(instance,
Hello,
I have tried another tiny script variant out for the semantic patch language
(according to the software combination “Coccinelle 1.0.8-00159-g730dbb03”).
@display@
identifier array, instance;
type T;
@@
*sizeof( \( T \| *(instance->array) \) )
elfring@Sonne:~/Projekte/Coccinelle/Probe>
> > Add an imperfect test to detect these comma uses.
> >
> > No false positives were found in testing, but many types of false negatives
> > are possible.
> >
> > e.g.:
> > foo = bar() + 1,/* comma use, but not direct assignment */
> > bar = baz();
>
> Hi.
>
> I recently added a
> The problem has nothing to do with disjunctions.
Can missing source code matches trigger the consequence that questionable
branches would be applied there?
Will the clarification for the issue “failing tests - TODO” be continued?
Regards,
Markus
___
> I will see if it can be fixed.
How will the issue “failing tests - TODO” evolve further?
https://github.com/coccinelle/coccinelle/commit/f2d7ec9006c89610bd1aab4662fcf100e3e6d469#diff-13ff769079511ec7b5dddef7143b2b93R1
How do the comments there fit to undesirable effects for SmPL disjunctions?
How do you think about to extend a source code search pattern like the following
by using a regular expression as a SmPL constraint?
@display@
format F =~ "l{0,2}[diuxX]";
@@
*\("%@F@" \| "%@F@\n"\)
Regards,
Markus
___
Cocci mailing list
> There are no short term plans for this.
Can long term development considerations be influenced for advanced data
processing
of format strings?
Regards,
Markus
___
Cocci mailing list
Cocci@systeme.lip6.fr
Can a source code search pattern like the following become ever usable?
@display@
@@
*"%"
("d"
|"ld"
|"lld"
)
("\n"
|""
)
elfring@Sonne:~/Projekte/Coccinelle/Probe> spatch --parse-cocci
show_usage_of_selected_format_strings.cocci
…
minus: parse error:
File
From: Markus Elfring
Date: Fri, 14 Aug 2020 08:56:54 +0200
* Reuse existing functionality from vmemdup_user() instead of keeping
duplicate source code.
Generated by: scripts/coccinelle/api/memdup_user.cocci
* See also:
[PATCH] drm/nouveau/gem: fix err_cast.cocci warnings
* Simplify
> the usage of the makefile C variable flag by coccicheck.
* Can it be confusing to denote an item as a variable and a flag?
* Would you really like to stress here that a flag can be variable?
> +This variable can be used to run scripts for …
Can the scope for a make command be selected also
From: Markus Elfring
Date: Sun, 9 Aug 2020 11:11:20 +0200
Another patch rule was added. A bit of code was copied from a previous
SmPL rule for this change specification.
* Thus reduce duplicate code by using another SmPL disjunction.
* Increase the precision a bit for desired source code
> Modify coccinelle documentation to further clarify
> the usage of the makefile C variable flag by coccicheck.
How do you think about a wording variant like the following
for the change description?
Clarify the usage of the make variable “C” for coccicheck.
> +C flag is used. The C flag is
…
> +++ b/tests/metaattr.cocci
> @@ -0,0 +1,9 @@
> +@@
> +attribute name __attr__;
> +attribute a;
> +identifier b;
> +@@
> +
> +-int
> ++char
> + b a = 1;
I have got understanding difficulties for this test SmPL script.
I interpret such SmPL code in the way that the metavariable
…
> +++ b/tests/metaattr.c
> @@ -0,0 +1,5 @@
> +int main() {
> + int b __attr__ = 1;
> + int b = 1;
> + return 0;
> +}
* Should such test code really work with a repeated definition of
the variable “b”?
* Would you like to test here if the identifier “b” should be handled
as an
From: Markus Elfring
Date: Wed, 8 Jul 2020 19:09:59 +0200
It can happen that function implementations with the return type “void”
call a special function at the end of if branches.
Such calls are occasionally followed by an immediate return.
The same function can be called at the end
Hello,
I have tried another tiny script variant out for the semantic patch language
(according to the software combination “Coccinelle 1.0.8-00139-gd0fd4c7d”).
@addition@
identifier work;
expression action;
@@
void work(...)
{
... when any
+last_action:
action(...);
}
Such a simple
Hello,
I have tried another tiny script variant out for the semantic patch language
(according to the software combination “Coccinelle 1.0.8-00131-g675b9670”).
@display@
expression* pointer;
identifier result;
type t;
@@
t result = <+...
( sizeof(*(pointer))
|
* *(pointer)
)
I assumed that I may omit the semicolon in such a SmPL code.
Can the specification of a SmPL nest construct ever be sufficient here?
>>>
>>> No. <+... ...+> matches a subtree of an AST. For a variable
>>> initialization, there is no subtree of the AST that includes both the
>>> right
>> I assumed that I may omit the semicolon in such a SmPL code.
>> Can the specification of a SmPL nest construct ever be sufficient here?
>
> No. <+... ...+> matches a subtree of an AST. For a variable
> initialization, there is no subtree of the AST that includes both the
> right side of an =
>> <+... when any
>> (t2 y = <+...
>> ( sizeof(*(resource))
>> |
>> * *(resource)
>> ) ...+>
>
> You are missing a ; here.
I assumed that I may omit the semicolon in such a SmPL code.
Can the specification of a SmPL nest construct ever be sufficient here?
Regards,
Markus
Hello,
I have tried another small script variant out for the semantic patch language
(according to the software combination “Coccinelle 1.0.8-00131-g675b9670”).
@display@
type t1, t2;
expression action;
identifier resource, y;
statement is, es;
@@
t1* resource;
<+... when any
(t2 y = <+...
(
Hello,
I have tried another tiny script variant out for the semantic patch language
(according to the software combination “Coccinelle 1.0.8-00131-g675b9670”).
@display@
expression* x;
statement is, es;
@@
*if (!x)
is
else
es
elfring@Sonne:~/Projekte/Coccinelle/janitor> spatch
Hello,
I know that the following SmPL script example gets accepted
by the Coccinelle software.
@display@
expression x, y;
@@
*y = ... *(x) ...
I have tried another tiny script variant out for the semantic patch language
(according to the software combination “Coccinelle
elfring@Sonne:~/Projekte/Linux/next-patched> spatch
--include-headers-for-types
~/Projekte/Coccinelle/janitor/use_devm_platform_get_and_ioremap_resource3.cocci
drivers/i2c/busses/i2c-rcar.c
>>>
>>> No, include headers for types doesn't have any impact on how many header
>>>
> (
> * size = E1 * E2;@p
> |
> * size = E1 * E2 * E3;@p
> |
> * size = E1 * E2 + E3;@p
> )
I suggest to reconsider also the order of elements for such a SmPL disjunction.
Can a computation like “E2 * E3” also be matched by the expression
metavariable “E2” alone?
Regards,
Markus
I propose once more to avoid a typo in the previous patch subject.
…
> (
> - size = E1 * E2;
> + size = array_size(E1, E2);
> |
> - size = E1 * E2 * E3;
> + size = array3_size(E1, E2, E3);
> |
> - size = E1 * E2 + E3;
> + size = struct_size(E1, E2, E3);
> )
How do you think about to use SmPL
>> I am going to present similar questions occasionally.
>
> Please stop.
I hope that I can continue as usual for while according to a desire
to achieve further improvements.
> The chance that people will help you will increase.
This would be nice.
> No one is interested in quantifying
> *void * __iomem action(...)
> {...}
>
> It's not quite in line with the what-you-see-is-what-you-get principle,
> but it'll work for your use case.
Usable output is produced after the adjusted position for the macro.
elfring@Sonne:~/Projekte/Linux/next-patched> spatch
> I'm away from my computer right now so can't test this, but try declaring
> __iomem as an attribute:
@display@
attribute name __iomem;
identifier action;
@@
*void __iomem * action(...)
{ ... }
elfring@Sonne:~/Projekte/Coccinelle/janitor> spatch --parse-cocci
show_iomem_functions2.cocci
…
Hello,
The support for data processing with attributes was extended recently.
https://github.com/coccinelle/coccinelle/commits?q=committer-date%3A%3C2020-06-16
Under which circumstances will a source code analysis approach become supported
by a script (like the following) for the semantic patch
>> +virtual report, org, context, patch
>>
>> Is such a SmPL code variant more succinct?
>
> This doens't matter.
Can less duplicate code be a bit nicer?
>>> +ssize_t show(struct device *dev, struct device_attribute *attr, char *buf)
>>> +{
>>> + <...
>>> +* return snprintf@p(...);
>>> +
> +// Confidence: High
Would you like to add any suggestion for a possible patch message?
…
> +virtual report
> +virtual org
> +virtual context
> +virtual patch
+virtual report, org, context, patch
Is such a SmPL code variant more succinct?
…
> +ssize_t show(struct device *dev, struct
…
> +virtual context
> +virtual patch
> +virtual org
> +virtual report
+virtual context, patch, org, report
Is such a SmPL code variant more succinct?
…
> +if (...)
> + \(memset@ok\|memzero_explicit@ok\)(...);
Would you like to tolerate any extra source code around such a function call
in an
I suggest to avoid a typo in the previous patch subject.
…
> +virtual context
> +virtual report
> +virtual org
+virtual context, report, org
Is such a SmPL code variant more succinct?
…
> +@as_next@
> +expression subE1 <= as.E1;
> +expression as.E1;
…
I propose to reduce the repetition of
> > Note2: https://github.com/coccinelle/coccinelle/blob/master/install.txt
> > says that 'spatch' is a script, but it seems to be a binary executable file.
>
> Actually, it is a script, and the fact that you say it is a binary may be
> the reason for your python problem. Normally there is a
> … Looks like it's impossible to break "when" lines.
Thus I became also curious on clarification for further software
development possibilities around the safer application of code exclusion
specifications by the means of the semantic patch language.
Regards,
Markus
> The following commits introduced some poor management of attributes in
arity.ml:
> 08f1cd9fb83ec400435e0ad8fdf579ec8f9c0f21
> b4b8653bd5a9607922e0050fe2fede10d422b218
I suggest to specify also subjects for such commit references.
> Apply mcode2arity to macrodecl and parameter
>> @display@
>> expression e;
>> @@
>> *brelse(e);
>> <+... when != e = ...
>> (e = ...
>> |
>> *e
>> )...+>
>>
>>
>> I would find it nicer if I do not need to repeat a code exclusion
>> specification
>> as the first element of a SmPL disjunction for this special use case.
>
> You don't. The
>> I hoped that my specification of a SmPL code exclusion should prevent
>> the presentation of assignments (independent from statements and/or
>> expressions).
>
> (
> e = e1
> |
> *e
> )
@display@
expression e;
@@
*brelse(e);
<+... when != e = ...
(e = ...
|
*e
)...+>
I would find it nicer
>> @display@
>> expression e;
>> @@
>> *brelse(e);
>> <+... when != e = ...
>> *e
>> ...+>
…
>> elfring@Sonne:~/Projekte/Linux/next-patched> spatch
>> ~/Projekte/Coccinelle/janitor/show_questionable_brelse_usage8.cocci
>> fs/ext4/extents.c
>> …
>> @@ -1127,8 +1121,6 @@ static int
> That is quite normal. One statement should be followed by another statement.
I have tried another script variant out for the semantic patch language.
@display@
expression e;
@@
*brelse(e);
<+... when != e = ...
*e
...+>
I wonder about the generation of a diff hunk then like the
>> If I omit the specification “, ...” from the function call parameters
>> because I could be unsure about the number of arguments in other
>> software situations, I do not get the desired test output as before.
>
> This has been discussed before.
I was just looking for a related update in this
Hello,
My software development attention was caught also by a recent patch.
https://lore.kernel.org/linux-fsdevel/20200608141629.GA1912173@mwanda/
https://lore.kernel.org/patchwork/patch/1253499/
Thus I have tried another tiny script out for the semantic patch language
(according to the software
…
> +++ b/scripts/coccinelle/api/memdup_user.cocci
> @@ -20,7 +20,9 @@ expression from,to,size;
…
> +- to = \(kmalloc\|kzalloc\)
> + (size,\(GFP_KERNEL\|GFP_USER\|
> + \(GFP_KERNEL\|GFP_USER\)|__GFP_NOWARN\));
I got the impression that this SmPL code needs another
…
> +++ b/scripts/coccinelle/api/memdup_user.cocci
> @@ -14,13 +14,24 @@ virtual patch
> virtual context
> virtual org
> virtual report
> +virtual selfcheck
Would you like to avoid the repetition of a SmPL key word here?
+virtual patch, context, org, report, selfcheck
> @@ -117,3 +128,34 @@
1 - 100 of 1468 matches
Mail list logo
