> The rule now properly checks that the third argument is the size of the
> first argument. This made a small reduction in the number of results.
Thanks for your SmPL script adjustments.
Will deviations from this restriction become more interesting?
> \(strscpy\|strlcpy\)(e1.f, e2, i2)@p
Would
> Huh? Rule 2 is important, to ensure that ths size is correct.
I assume that the dependency of the replacement on the data structure check
can become clearer.
Regards,
Markus
> @r@
> identifier f,i1,i2;
> struct i1 e1;
> expression e2;
> position p;
> @@
> \(strscpy\|strlcpy\)(e1.f, e2, i2)@p
I have got the impression that the replacement can work also
without an inherited position variable at the end.
How do you think about to omit this SmPL rule then?
Can it be nice
>>> @@
>>> (
>>> -x = strlcpy
>>> +stracpy
>>> (e1.f, e2
>>> -, i2
>>> )@p;
>>> ... when != x
>>>
>>> |
>>
>> I wonder about the deletion of the assignment target.
>> Should the setting of such a variable be usually preserved?
>
> If it is a local variable and never subsequently used, it
> New version. I check for non-use of the return value of strlcpy and
> address some issues that affected the matching of the case where the first
> argument involves a pointer dereference.
I suggest to take another look at corresponding implementation details
of the shown SmPL script.
> \(strs
>> Will further software development considerations become more interesting
>> also around a contribution like “Coccinelle: Add a SmPL script for
>> the reconsideration of redundant dev_err() calls”?
>> https://lore.kernel.org/lkml/2744a3fc-9e67-8113-1dd9-43669e063...@web.de/
>> https://lore.kernel
>>> +if (ret != -EPROBE_DEFER)
>>
>> Is it appropriate to treat this error code check as optional
>> by the shown transformation approach?
>> Can this case distinction be omitted?
>
> I don't know what you mean here.
I suggest to take another look at the importance and relevance
of this specific s
> +@script:python depends on org@
> +p1 << r.p1;
> +@@
> +
> +cocci.print_main(p1)
Will an additional message be helpful at this place?
Will further software development considerations become more interesting
also around a contribution like “Coccinelle: Add a SmPL script for
the reconsideration
> > > struct platform_device *E;
How much does this specification matter for the parameters
of the mentioned functions (in the SmPL script)?
Will the selection of function names be sufficient for the discussed
source code search pattern?
> > Can you teach it to remove curly braces when it's appr
I would prefer to concentrate the usage of SmPL disjunctions on changing
implementation details so that the specification of duplicate code
can be avoided.
> +(
> +platform_get_irq(E, ...)
> +|
> +platform_get_irq_byname(E, ...)
> +);
Function names:
+(platform_get_irq
+|platform_get_irq_byname
> But I also write tools that
use the Go AST package to rewrite Go,
Would you like to share any more experiences around related software?
> and have never felt the lack of
coccinelle for Go.
I find this impression interesting.
How much did you get used to functionality which is supported by
t
> We are looking into
using Coccinelle for refactoring in Go
Thanks for your interest.
> Does Coccinelle include support for Go?
Not yet.
> * Is there any plan to add support for the same?
Would you like to contribute significant development resources for
corresponding software extensions?
> Finally, this patch finds use-after-free issues for a node.
> (implemented by the r_use_after_put rule)
I suggest to take another look also at information from a clarification attempt
on a topic like “Checking statement order for patch generation with SmPL
support”.
https://systeme.lip6.fr/pipe
> Finally, this patch finds use-after-free issues for a node.
> (implemented by the r_use_after_put rule)
I suggest to take another look also at information from a clarification attempt
on a topic like “Checking statement order for patch generation with SmPL
support”.
https://systeme.lip6.fr/pipe
> 2), Then SmPL A generates another SmPL B based on the function name list;
This would be a general data processing possibility.
Another option would be to let SmPL scripts to import relevant data
from external files or to query facts from databases.
> You expect the entire process above to be a
>> Why would you like to keep this SmPL code in the commit description?
>
> I don't know indetail what you are proposing,
I imagine that you can get more interesting software development ideas
from links to previous messages.
I hope that the desired clarification can become more constructive.
How
>> Why would you like to keep this SmPL code in the commit description?
>
> I don't know indetail what you are proposing,
I imagine that you can get more interesting software development ideas
from links to previous messages.
I hope that the desired clarification can become more constructive.
How
> We find these functions by using the following script:
Why would you like to keep this SmPL code in the commit description?
I would prefer software evolution in an other direction.
https://lore.kernel.org/lkml/44be5924-26ca-5106-aa25-3cbc3343a...@web.de/
https://lkml.org/lkml/2019/7/4/21
> @i
My software development attention was caught also by your proposal.
I would appreciate a message subject without a typo.
> +virtual patch
> +virtual context
> +virtual org
> +virtual report
These metavariables are not used in the subsequent code in this approach
for the semantic patch language.
> we recently have lots of patches for either adding missing NULL checks,
> removing unneeded ones, etc.
Would you like to point any more concrete change examples out?
> It seems that's an non-trivial terrain,
This area can be also challenging.
> so I'm thinking about potential compiler sup
> Has anyone attempted to port coccinelle to OCaml 4.08?
I am unsure also about this detail.
> It seems
to require multiple complex changes.
I am waiting on corresponding software improvements according to a report
like “Checking dependencies for current OCaml compiler version”.
https://system
> But I wonder at the moment why it does not work (as expected) for the original
> complete source file.
I discovered that a diff hunk (or usable patch?) is generated
if the return statement is deleted (or commented out) before the jump label
which refers to a potentially unwanted function call at
> 110: ierr_out:
> 111: of_node_put(trng); ---> double released here
> ...
>
> This issue was detected by using the Coccinelle software.
Such a detection of a questionable source code place can be nice and helpful.
I constructed another script variant for the semantic patch languag
>>> How do you think about to increase the matching granularity
>>> for this functionality?
>>
>> No idea what this means. Disjunctions are expanded up to the level of the
>> nodes in the control-flow graph.
>
> We have got different expectations for working with such nodes
> for possible (data fl
>> I will apply with Julia's Signed-off-by instead of Acked-by.
>> I will also add SPDX tag.
>>
>> Is this OK?
>
> Yes, thanks.
Will the clarification for following implementation details get any more
software development attention?
https://systeme.lip6.fr/pipermail/cocci/2019-June/005975.ht
>> @script:python depends on report && r1@
>
> No need to depend on r1. That is guaranteed by the inheritance on the
> metavariables below.
Will this information become more helpful for the completion of the
corresponding
software documentation?
Regards,
Markus
>> elfring@Sonne:~/Projekte/Coccinelle/Probe> spatch
>> ../janitor/use_call_with_ternary_operator1.cocci ksm-excerpt1.c
>> …
>> +list_add_tail(&mm_slot->mm_list,
>> + (ksm_run & KSM_RUN_UNMERGE) ? &ksm_mm_head.mm_list :
>> &ksm_scan.mm_slot->mm_list);
>
> And this is unsatisf
>> Would you like to achieve any improvements for automatic code beautification?
>> https://github.com/coccinelle/coccinelle/issues/37
>
> If you want to report a problem,
I became curious again if more contributors would become interested
to influence a possibly known software situation a bit mor
Hello,
The semantic patch language supports also to convert conditional statements
into usages of the ternary operator.
How much can the Coccinelle software help with pretty-printing of generated
source code in this area?
Would you like to achieve any improvements for automatic code beautification
> We tested and found that both <...x...> and <+... x ...+> variants work fine.
Is the difference in the functionality from this SmPL construct clear already?
> We use <... x ...> instead of <+... x ...+> here to eliminate the following
> false positives:
Do we stumble on another software desi
> We will also provide an example written in Python later.
Will the code move from the commit description into a file
for your next patch version?
> We first use this script to find out all the function names to be processed,
I am still curious on how the output format selection will become cle
> By the way: do we have any mechanism for explicitly suppressing
> individual warnings (some kind of annotation),
I do not know such an accepted specification interface
(for the handling together with SmPL scripts) so far.
How would you identify possibly unwanted messages in a safe way?
> when
From: Markus Elfring
Date: Mon, 1 Jul 2019 10:00:39 +0200
The function “devm_ioremap_resource” contains appropriate error reporting.
Thus it can be questionable to present another error message
at other places.
Provide design options for the adjustment of affected source code
by the means of
> Please actually try things out before declaring them to be useless.
This feedback provides also another opportunity for collateral evolution
in some directions. I am curious on how involved uncertainty can be fixed around
possibly different interpretation for provided software functionality.
Th
+if (x == NULL || ...) S
+... when != e = (T)x
+when != true x == NULL
…
> I assume that it was added because it was found to be useful.
We can get different software development opinions also on
this implementation detail.
> Please actually try things out before declaring the
>> +if (x == NULL || ...) S
>> +... when != e = (T)x
>> +when != true x == NULL
>
> I wonder if this code exclusion specification is really required
> after a null pointer was checked before.
I would like to add another view for this implementation detail.
The when constraint can express a so
>> +x =
>> +(of_…
>> +|of_…
>> +)@p1(...);
>
> Did you actually test this? I doubt that a position metavariable can be
> put on a ) of a disjunction.
Would you ever like to support this possibility?
>> +|return
>> +(x
>> +|of_fwnode_handle(x)
>> +);
>
> The original code is much more readable.
>> +x =
>> +(of_…
>> +|of_…
>> +)@p1(...);
>
> Did you actually test this? I doubt that a position metavariable can be
> put on a ) of a disjunction.
Would you ever like to support this possibility?
>> +|return
>> +(x
>> +|of_fwnode_handle(x)
>> +);
>
> The original code is much more readable.
> The counter must be decremented after the last usage of a device node.
Thanks for your next try to improve the software situation
also in this area.
> We find these functions by using the following SmPL:
Would it be nicer to use the word “script” also here?
>
> @initialize:ocaml@
> @@
How
>> Where did the Coccinelle software get the impression that anything
>> would be added too often at the end of such a function implementation?
>
> Without the semantic patch and the C source code,
You have access to data from both files already.
> I can't answer the question.
Is it more conven
>> replacement: already tagged token:
>
> You try to add two things one one token, which is not allowed.
How do you think about to clarify why a source file adjustment
like the following can let my SmPL script succeed in a test configuration?
elfring@Sonne:~/Projekte/Coccinelle/Probe> diff -u meg
>>> You can try with the option --debug.
>>> Or if that doesn't help with the option --verbose-ctl-engine.
>>
>> How can these parameters help to clarify undesirable run time
>> characteristics?
>
> How about actually looking at the results yourself?
I did that. - I do not find these extra data s
> Maybe there are too many metavariable bindings.
Under which circumstances would such a situation really occur?
How do you think about my SmPL script example for the shown use case?
> You can try with the option --debug.
> Or if that doesn't help with the option --verbose-ctl-engine.
How can
> * The complete source file seems to be very challenging for testing
> the run time characteristics.
How are the chances to clarify the different test results for this source code
transformation approach with the software combination “Coccinelle
1.0.7-00211-geaa13d59-dirty
(OCaml 4.07.1)”?
el
> @@
> expression x;
> constant c1,c2;
> @@
>
> x = c1;
The SmPL manual contains the promising wording “As metavariables are bound
and inherited across rules, …”.
https://github.com/coccinelle/coccinelle/blob/c6d7554edf7c4654aeae4d33c3f040e300682f23/docs/manual/cocci_syntax.tex#L179
The mentioned
> @@
> expression x;
> constant c1,c2;
> @@
>
> x = c1;
> (
> x = c1;
> |
> *x = c2;
> )
Thanks for your suggestion of the possible usage of a SmPL disjunction.
* Does it indicate a search attempt to match the first assignment statement
twice
(for the implementation of exclusion of duplicate s
> The expected difference can trigger the need to express this detail
> by the usage of two identifiers based on the same metavariable type.
I guess that this wording should be clarified a bit more according to
the current software development status around the semantic patch language.
A selection
Hello,
The semantic patch language supports metavariables.
It can occur then that a source code search should be performed for items
which should be different while they belong still to the same data type.
(If these items would be identical, the software situation would provide
opportunities to si
Am 23.06.19 um 15:13 schrieb Julia Lawall:
>
>
> On Sun, 23 Jun 2019, Markus Elfring wrote:
>
>>> Try
>>>
>>> ... when any
>>>
>>> just before the final ). In some circumstaces the parser doesn't accept
>>> an expression a
> Try
>
> ... when any
>
> just before the final ). In some circumstaces the parser doesn't accept
> an expression at the end of a sequence like you have here.
Thanks for your quick response.
The addition of such a SmPL ellipsis helps somehow.
But I am still not pleased with the generated transf
> Try
>
> ... when any
>
> just before the final ). In some circumstaces the parser doesn't accept
> an expression at the end of a sequence like you have here.
Thanks for your quick response.
The addition of such a SmPL ellipsis helps somehow.
But I am still not pleased with the generated transf
> Yu can do whatever you want, but you will get lotsof false positives if
> you keep it. If you really want a star on the declaration then you need
> to make two rules. The first that finds the positions of the places that
> match and the second that only puts a * when there is both a matched
> d
> Yu can do whatever you want, but you will get lotsof false positives if
> you keep it. If you really want a star on the declaration then you need
> to make two rules. The first that finds the positions of the places that
> match and the second that only puts a * when there is both a matched
> d
>>> It could be helpful to replace the last line by:
>>>
>>> (
>>> e3 = <+...var...+>
>>
>> Can this SmPL specification make sense as another when constraint?
>
> No.
I imagine that a few extensions like the following can become safer.
when != do ds while( \( var bo e3 \| var \) );
wh
>>> In that case, it would also be beneficial to remove the *
>>
>> I find the asterisk required here
>
> Yu can do whatever you want, but you will get lotsof false positives if
> you keep it. If you really want a star on the declaration
I would prefer to use a minus character for the specificati
> It could be helpful to replace the last line by:
>
> (
> e3 = <+...var...+>
Can this SmPL specification make sense as another when constraint?
> |
> * var = e3
> )
>
> In that case, it would also be beneficial to remove the *
I find the asterisk required here
> on the variable declaration
>> elfring@Sonne:~/Projekte/Linux/next-patched> spatch
>> ~/Projekte/Coccinelle/janitor/show_questionable_variable_initialisation1.cocci
>> drivers/misc/lkdtm/core.c
>> …
>> exn while in timeout_function
>> Fatal error: exception Coccinelle_modules.Common.Impossible(56)
>>
>>
>> How do you think
Hello,
I have tried out to build the current Coccinelle software again based on
the OPAM switch “4.08.0”.
Unfortunately, I stumble on the following error message.
…
ocamlfind ocamlc -c -no-alias-deps -I . stdcompat__pervasives.ml -o
stdcompat__pervasives.cmo
File "stdcompat__pervasives.ml", li
Hello,
I became interested in another source code transformation again.
I would like to move a bit of common code to the end of a function
implementation
with the help of the following script for the semantic patch language.
@replacement@
expression info, result;
identifier target, work;
type t
> I still don't see the point of specifying return. Why not just S, where S
> is a statement metavariable?
Do you find the following SmPL change specification more appropriate?
@deletion depends on patch@
expression e;
statement s;
@@
e = devm_ioremap_resource(...);
if (IS_ERR(e))
(
-{
- dev
> I still don't see the point of specifying return. Why not just S, where S
> is a statement metavariable?
Do you find the following SmPL change specification more appropriate?
@deletion depends on patch@
expression e;
statement s;
@@
e = devm_ioremap_resource(...);
if (IS_ERR(e))
(
-{
- dev
> I think that something like
>
> if (IS_ERR(e))
> {
> <+...
> *dev_err(...)
> ...+>
> }
>
> would be more appropriate. Whether there is a return or not doesn't
> really matter.
Do you find the following SmPL change specification useful and acceptable?
@deletion depends on patch@
expression e;
>> Would you prefer to clarify a more advanced approach?
>
> I think that something like
>
> if (IS_ERR(e))
> {
> <+...
> *dev_err(...)
> ...+>
> }
>
> would be more appropriate.
This SmPL construct can be more powerful.
> Whether there is a return or not doesn't really matter.
Such an adjustme
>> +@display depends on context@
>> +expression e;
>> +@@
>> + e = devm_ioremap_resource(...);
>> + if (IS_ERR(e))
>> + {
>> +* dev_err(...);
>> +return (...);
>> + }
>
> Why do you assume that there is exactly one dev_err and one return after
> the test?
I propose to start with the addition
>> +@display depends on context@
>> +expression e;
>> +@@
>> + e = devm_ioremap_resource(...);
>> + if (IS_ERR(e))
>> + {
>> +* dev_err(...);
>> +return (...);
>> + }
>
> Why do you assume that there is exactly one dev_err and one return after
> the test?
I propose to start with the addition
From: Markus Elfring
Date: Thu, 20 Jun 2019 19:12:53 +0200
The function “devm_ioremap_resource” contains appropriate error reporting.
Thus it can be questionable to present another error message
at other places.
Provide design options for the adjustment of affected source code
by the means of
Hello,
A patch on a topic like “[next] lkdtm: remove redundant initialization of ret”
caught also my software development attention.
https://lkml.org/lkml/2019/6/14/265
https://lore.kernel.org/patchwork/patch/1088971/
https://lore.kernel.org/lkml/20190614094311.24024-1-colin.k...@canonical.com/
>> Would you like to add this information to the software documentation?
>
> Not really. The documentation can't defend against everyone's imagination.
Will it become helpful to mention the metavariable type “expression *”
also in the SmPL manual?
https://github.com/coccinelle/coccinelle/blob/cad
>> Would you like to add this information to the software documentation?
>
> Not really. The documentation can't defend against everyone's imagination.
Will it become helpful to mention the metavariable type “expression *”
also in the SmPL manual?
https://github.com/coccinelle/coccinelle/blob/cad
> You can't specify pointer dereferences by metavariables.
Thanks for another clarification for a detail by the Coccinelle software.
I assumed that this would be useful functionality for the specification
“expression *X;”.
> The pattern is only in the pattern. It is not partly in the metavaria
>>> Metavariables have types. Here X has pointer type.
>>
>> Our understanding of this software detail seems to match.
>>
>> But I assume that the asterisk can be treated in a different way by
>> the isomorphism definition language in comparison to the semantic
>> patch language.
>> How much does
>> https://github.com/coccinelle/coccinelle/blob/19ee1697bf152d37a78a20cefe148775bf4b0e0d/standard.iso#L151
>>
>> It looks like that it should refer to a pointer dereference
>> (according to a view for the semantic patch language).
>> But the really desired meaning might be different for the suppor
> How would Coccinelle know that a pointer is expected if there is no asterisk?
I am still trying to achieve a better understanding around the interpretation
of the specification “expression *X;”.
https://github.com/coccinelle/coccinelle/blob/19ee1697bf152d37a78a20cefe148775bf4b0e0d/standard.iso#L
> How would Coccinelle know that a pointer is expected if there is no asterisk?
SmPL expression metavariables can handle also pointer variables from C code,
can't they?
Type distinctions have got other consequences for isomorphism definitions.
Regards,
Markus
> Isomorphisms have a cost, so the provided isomorphism only converts !X to
> X == NULL when X is a pointer.
It seems that the Coccinelle software has got restrictions on
the interpretation of pointers so far.
Is a pointer recognised for application of isomorphisms by
the semantic patch language o
>> Would you like to check the software circumstances once more
>> for the generation of a similar code structure by a C compiler
>> (or optimiser)?
>
> As said: unfortunately, I don't have the time to do that
I became curious if you would like to adjust your software development
attention a bit m
> If you turn off isomorphisms, it will only match exactly what you have
> written.
This setting can occasionally be appropriate.
> Isomorphisms have a cost, so the provided isomorphism only converts !X to
> X == NULL when X is a pointer. If you want to make an isomorphism that
> does somethin
> As I already told you, the isomorphisms are applied before matching
> against the C code. At that time, this information is not available.
Can the software situation be clarified also by omitting Coccinelle's
isomorphisms?
(Can this functionality be temporarily switched off for a specific SmPL
>> Two function calls were combined in this function implementation.
>> Inline corresponding code so that extra error checks can be avoided here.
>
> What exactly is the purpose of this ?
I suggest to take another look at the need and relevance of involved
error checks in the discussed function co
>> Example:
>> struct setkey_parm *psetkeyparm;
>
> As I already told you, the isomorphisms are applied before matching
> against the C code. At that time, this information is not available.
Under which circumstances will the Coccinelle software become able
to take available data type inform
>> Can the mentioned SmPL script variant work also without taking extra
>> software transformations by isomorphism specifications into account?
>
> Well, you already know that it doesn't. So oviously the answe is that it
> cannot.
At the moment.
> If you indicate that the expression ex is a po
> Isomorphisms happen in advance, not during the matching process.
Can the mentioned SmPL script variant work also without taking extra
software transformations by isomorphism specifications into account?
Regards,
Markus
___
Cocci mailing list
Cocci@sys
>> Should an isomorphism specification like “not_ptr2” help here?
>> https://github.com/coccinelle/coccinelle/blob/19ee1697bf152d37a78a20cefe148775bf4b0e0d/standard.iso#L157
>
> No, because Coccinelle does not know that it is a pointer.
> How should it know?
Can the software determine that the exp
> In the second case, Coccinelle has no way of knowing that ex is a pointer,
Can the software support pointer expressions better?
> so it doesn't feel motivated to consider that ex should be compared to NULL.
Should an isomorphism specification like “not_ptr2” help here?
https://github.com/cocc
Hello,
A patch on a topic like “staging/rtl8723bs/core/rtw_ap: Remove redundant call
to memset” caught also my software development attention.
https://lkml.org/lkml/2019/6/15/220
https://lore.kernel.org/patchwork/patch/1089416/
https://lore.kernel.org/lkml/20190616033527.GA14062@hari-Inspiron-1545
>> Two function calls were combined in this function implementation.
>> Inline corresponding code so that extra error checks can be avoided here.
>
> I don't see any point to this at all.
Would you like to take another look at corresponding design options?
How do you think about to check run time
From: Markus Elfring
Date: Fri, 14 Jun 2019 11:05:33 +0200
Two function calls were combined in this function implementation.
Inline corresponding code so that extra error checks can be avoided here.
Signed-off-by: Markus Elfring
---
drivers/base/platform.c | 39
> Apparently I'm missing this obscure line in the documentation:
>
> "Fresh identifier metavariables must only be used in + code."
>
> Any suggestions on how to work around this, other than use Python?
Would you get into the mood to adjust this software situation any more?
(Increase OCaml developm
>> The flag “IORESOURCE_MEM” is passed as the second parameter for the call
>> of the function “platform_get_resource” in this refactoring.
>
> In that particular case, we maybe should consider separate inline
> helpers instead of passing this is a parameter.
>
> Maybe it would even be more efficie
Am 10.06.19 um 23:00 schrieb Julia Lawall:
>
>
> On Sun, 9 Jun 2019, Markus Elfring wrote:
>
>> Hello,
>>
>> The Coccinelle software supports also a variant of parallel data processing
>> after the parameter “--jobs” was passed.
>> htt
> https://github.com/coccinelle/coccinelle/issues/50
Would you like to adjust the situation around better software collaboration?
https://docs.sqlalchemy.org/en/13/core/pooling.html#using-connection-pools-with-multiprocessing
Regards,
Markus
___
Cocci m
Hello,
The Coccinelle software supports also a variant of parallel data processing
after the parameter “--jobs” was passed.
https://github.com/coccinelle/coccinelle/blob/7ec31ed1fadf738bc487ccefdc63bfe0598f44cc/docs/manual/spatch_options.tex#L745
It is nice when it works to distribute analysis on
>>> +- e1 = devm_ioremap_resource(arg4, id);
>>> ++ e1 = devm_platform_ioremap_resource(arg1, arg3);
>>
>> Can the following specification variant matter for the shown SmPL
>> change approach?
>>
>> + e1 =
>> +- devm_ioremap_resource(arg4, id
>> ++ devm_platform_ioremap_resource(arg1, arg3
> +- e1 = devm_ioremap_resource(arg4, id);
> ++ e1 = devm_platform_ioremap_resource(arg1, arg3);
Can the following specification variant matter for the shown SmPL
change approach?
+ e1 =
+- devm_ioremap_resource(arg4, id
++ devm_platform_ioremap_resource(arg1, arg3
+
> Would you like to try another SmPL script variant out?
@replacement@
constant text;
expression value;
@@
.driver = {
- .name = text,
- .of_match_table = value,
- },
+ .name = text,
+ .of_match_table = of_match_ptr(value),
+ },
How do you t
> Just wrapping the assignment into the macro call turned out to be easy.
I am curious how your transformation approaches will evolve further.
> But I haven't found a way to remove the now #ifdef :(
The support for preprocessor functionality is limited by the semantic patch
language so far.
Wou
>> Will similar software updates become more challenging for the initially
>> described handling of designated initialisers for known data structures?
>
> This is in the spirit of the solution I already proposed.
Would you like to compare transformation results also for the following SmPL
change s
>> Will similar software updates become more challenging for the initially
>> described handling of designated initialisers for known data structures?
>
> This is in the spirit of the solution I already proposed.
How do you think about the following SmPL transformation approach?
@replacement@
con
> but not:
>
> @@
> @@
>
> - #ifdef FOO
> bar();
> - #endif
The deletion of these preprocessor statements is not directly supported
in the shown way by the Coccinelle software at the moment.
But I got another code transformation idea which would not be so convenient.
The semantic patch language
Hello,
I occasionally use the software “SQLAlchemy” for easy storage of source code
data.
I noticed once more that information was not permanently stored
if the parameter “-j 4” was passed to the program “spatch” while
the database “PostgreSQL 11.3-7.1” was selected as the desired storage system.
601 - 700 of 1817 matches
Mail list logo