Re: [Cocci] [v5] coccinelle: semantic code search for missing put_device()

2019-03-26 Thread Markus Elfring
> When I searched "Wen Yang", v6 did not show up for some reasons. > https://lore.kernel.org/patchwork/project/lkml/list/?series==22638=*=== I find such a situation also interesting somehow. I assume that there was another temporary technical difficulty involved with the Linux mailing list (and

Re: [Cocci] [v5] coccinelle: semantic code search for missing put_device()

2019-03-26 Thread Markus Elfring
>> So, I just thought v5 was the latest one >> and I was completely missing the context. > > I think it is a minor detail Additional implementation details were discussed also for this script of the semantic patch language. > that will have no impact in practice. It will take another while to

Re: [Cocci] RFC catching hidden code in if conditions

2019-03-26 Thread Markus Elfring
> Noticed that the nuveau driver uses a fair number of > if (var=val,boolean-condition){} > which while legal C-code just makes it hard to read > - and some seems buggy actually. Do you find another analysis approach nicer for the semantic patch language than the existing check “ASSIGN_IN_IF” by

Re: [Cocci] [PATCH] coccinelle: api: add devm_platform_ioremap_resource script

2019-04-06 Thread Markus Elfring
> +// Copyright: (C) 2019 Himanshu Jha GPLv2. How do you think about to use a SPDX identifier? > +// ---… I would prefer a SmPL script without such comment lines as delimiters here. > +position j0; Would the variable name “p” be nicer? > +@script:python depends on report && !patch@ > +e1

Re: [Cocci] Coccinelle: put_device: reduce false positives

2019-04-01 Thread Markus Elfring
> I added Fixes: tag, > and applied to linux-kbuild/fixes. Will this extension trigger further adjustments for similar SmPL scripts? Example:

Re: [Cocci] Introduction of HWMON_CHANNEL_INFO() macro with SmPL?

2019-03-31 Thread Markus Elfring
> @r@ > initializer list elements; When will a description be added to the SmPL manual for this metavariable? > identifier i; > @@ > > -static const u32 i[] = { > - elements, > - 0 > -}; Are any more constraints needed for such a deletion? > The elements of the array are considered to be

Re: [Cocci] Introduction of HWMON_CHANNEL_INFO() macro with SmPL?

2019-03-31 Thread Markus Elfring
> @r@ > initializer list elements; When will a description be added to the SmPL manual for this metavariable? > identifier i; > @@ > > -static const u32 i[] = { > - elements, > - 0 > -}; Are any more constraints needed for such a deletion? > The elements of the array are considered to be

Re: [Cocci] [PATCH] coccinelle: put_device: reduce false positives

2019-03-23 Thread Markus Elfring
> Don't complain about a return when this function returns ">dev". Would this information qualify to add the tag “Fixes” to the commit message? Regards, Markus ___ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] [v5] coccinelle: semantic code search for missing put_device()

2019-03-23 Thread Markus Elfring
> Applied to linux-kbuild. A questionable development version was integrated for this SmPL script. https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/scripts/coccinelle/free/put_device.cocci?id=da9cfb87a44da61f2403c4312916befcb6b6d7e8

Re: [Cocci] [v6] coccinelle: semantic code search for missing put_device()

2019-02-18 Thread Markus Elfring
>> Which data element should not get reassigned here (before a corresponding >> null pointer check)? >> > > Thank you for your comments. > We did some experiments: > +id = of_find_device_by_node@p1(x) > +... when != e = id > ... > Or: > ... > + ... when != id = e > > The number of issuses found by

[Cocci] Increasing warnings for potentially missed resource releases?

2019-03-04 Thread Markus Elfring
Hello, A few scripts demonstrate that it can be possible by the means of the semantic patch language to determine if a resource identification will not escape from a scope in an analysed function. I am still curious on how the clarification on corresponding implementation details will evolve

Re: [Cocci] [v6] coccinelle: semantic code search for missing put_device()

2019-02-19 Thread Markus Elfring
>> Will corrections become relevant for specifications in (assignment) >> exclusions >> of the second SmPL ellipsis in the discussed script? > > Let's do some experiments with the code in the current kernel. It seems that you provided additional information for the adjustment of when

Re: [Cocci] [v6] coccinelle: semantic code search for missing put_device()

2019-02-19 Thread Markus Elfring
> Do you have any other questions? Obviously, yes. I am curious if this development discussion and code review will trigger further software adjustments. I guess that you will need additional time to reconsider specific items from recent feedback. Will corrections become relevant for

Re: [Cocci] [v6] coccinelle: semantic code search for missing put_device()

2019-02-19 Thread Markus Elfring
>> Although we have tested these two methods in the existing kernel code, >> considering the evolution of the kernel code, these special cases may occur, >> so we are willing to take them into account. >> We plan to modify the code like this: >> >> id = of_find_device_by_node@p1(x) >> -... when

Re: [Cocci] Capturing comments / whitespace with statement list?

2019-02-21 Thread Markus Elfring
> Metavariables lose all of their whitespace and comments, Would you like to reconsider such details because of information from the documentation? “Coccinelle is a tool to help automate repetitive source-to-source style-preserving program transformations on C source code, like for instance to

Re: [Cocci] Specifying that an expression is a string constant?

2019-02-20 Thread Markus Elfring
>> The following rule fails with an error on the last line: >> >> @rule3@ >> expression x, y, z; >> @@ >> -DBG_PRINT_STRING_VALUE(x, y, z); >> +NV_PRINTF2(x, y "0x%x\n", z); >> >> Presumably, cocci doesn't know that "y" is a string constant and so >> the resulting expression is valid. I'm

Re: [Cocci] [v6] coccinelle: semantic code search for missing put_device()

2019-03-06 Thread Markus Elfring
> Do you have any other questions? I would like to point another aspect out for further development considerations. The initial assignment targets are (id)expressions in the discussed analysis approach so far. Would you like to care also for value (or pointer) initialisations by resource

[Cocci] Splitting a source code search specification from a SmPL rule into more rules?

2019-03-06 Thread Markus Elfring
Hello, The semantic patch language supports also to put longer code into SmPL rules. It might look convenient and appropriate to specify such code for a single SmPL rule. But it can happen also that you would like to reduce source code search efforts and present meaningful analysis reports.

[Cocci] Checking varying accesses to members of local variables with SmPL

2019-03-03 Thread Markus Elfring
Hello, The following information is provided in the manual for the semantic patch language. “A metavariable declaration local idexpression v means that v is an expression that is restricted to be a local variable. … A more complex description of a location, such as a->b is considered to be an

Re: [Cocci] [v5] coccinelle: semantic code search for missing put_device()

2019-03-17 Thread Markus Elfring
> Applied to linux-kbuild. How does this information fit to the published sixth version of the discussed script for the semantic patch language? https://lore.kernel.org/cocci/hk0pr02mb36344e2b29ceb195892f6420b2...@hk0pr02mb3634.apcprd02.prod.outlook.com/

Re: [Cocci] [PATCH] coccinelle: semantic patch for missing of_node_put

2019-03-15 Thread Markus Elfring
> +/// Find missing of_node_put > +/// > +// Confidence: Moderate How much would you like to improve the situation around recurring software development concerns for such source code analysis approaches? > +virtual report > +virtual org I would interpret the provided SmPL code in the way that

Re: [Cocci] [PATCH v6] coccinelle: semantic code search for missing put_device()

2019-02-17 Thread Markus Elfring
>>> +@search exists@ >>> +local idexpression id; >>> +expression x,e,e1; >>> +position p1,p2; >>> +type T,T1,T2; >>> +@@ >>> + >>> +id = of_find_device_by_node@p1(x) >>> +... when != e = id >> >> I suggest to increase your software development attention also for >> another implementation detail.

Re: [Cocci] [v6] coccinelle: semantic code search for missing put_device()

2019-02-17 Thread Markus Elfring
>> Would you dare to interpret my update suggestion (reordering of two >> identifiers) >> as a required SmPL script correction? > > I didn't suggest to reorder anything. This is obvious according to your acknowledgement for the sixth version of this evolving SmPL script. > Both are needed. If

Re: [Cocci] 答复: [v6] coccinelle: semantic code search for missing put_device()

2019-02-16 Thread Markus Elfring
> But please also refer to the examples of coccinelle, such as: > http://coccinelle.lip6.fr/rules/kmalloc.html > and > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/scripts/coccinelle/free/pci_free_consistent.cocci These scripts for the semantic patch language show some

Re: [Cocci] [PATCH v6] coccinelle: semantic code search for missing put_device()

2019-02-17 Thread Markus Elfring
> +@search exists@ > +local idexpression id; > +expression x,e,e1; > +position p1,p2; > +type T,T1,T2; > +@@ > + > +id = of_find_device_by_node@p1(x) > +... when != e = id I suggest to increase your software development attention also for another implementation detail. Source code analysis

Re: [Cocci] [v6] coccinelle: semantic code search for missing put_device()

2019-02-17 Thread Markus Elfring
>> If you would insist on the specification of such an assignment exclusion >> for a SmPL ellipsis: >> Can we agree on a correct order? > > I don't get your point. I propose to take another closer look at a bit of SmPL code. > There is no correct order. I have got an other software development

Re: [Cocci] Qualifiers for field types get lost

2019-02-14 Thread Markus Elfring
> I have this trivial script to remove useless casts to self: > @ disable drop_cast @ > type T; > T E; > @@ > - (T) > E > > It works but I'm hitting false positives when the code casts away > qualifiers for field types. Can this result be expected when your source code transformation

Re: [Cocci] [v4] coccinelle: semantic patch for missing put_device()

2019-02-14 Thread Markus Elfring
>> So I plan to modify the following to capture both cases: >> -local idexpression id; >> +expression id; > > I'm not sure that this is a good idea. Why have you got doubts here? > There is likely no need for a put in the latter case. I have got understanding difficulties for such information.

Re: [Cocci] [v4] coccinelle: semantic patch for missing put_device()

2019-02-14 Thread Markus Elfring
In a function, for variables returned by calling of_find_device_by_node(), >>> Do variables really get returned? >>> The provided pointer should usually be stored somewhere. >> >> Thank you very much, we will consider this situation and submit a next >> version to fix it. > > I don't know

Re: [Cocci] [v4] coccinelle: semantic patch for missing put_device()

2019-02-15 Thread Markus Elfring
> The whole goal of the semantic patch is to ensure that put_device is > called when needed. Thanks for this clarification. The software development goal seems to be clear to some degree. > If the value is stored in a structure, Will any further means become relevant for the discussed data

Re: [Cocci] [PATCH v5] coccinelle: semantic code search for missing put_device()

2019-02-15 Thread Markus Elfring
> In a function, for a local variable returned by calling > of_find_device_by_node(), I suggest to reconsider this information once more. 1. Will an other wording be more appropriate for the storage of a function return value? 2. Can the restriction “local” be omitted? 3. Will any macros be

Re: [Cocci] [v6] coccinelle: semantic code search for missing put_device()

2019-02-16 Thread Markus Elfring
> In a function, for a local variable obtained by of_find_device_by_node(), I got a software understanding where such a variable can not be obtained from this function call. The return value (like a pointer in this use case) can be stored there. > v6: > - to be double sure, replace >dev with

Re: [Cocci] [v6] coccinelle: semantic code search for missing put_device()

2019-02-17 Thread Markus Elfring
>> … >> +@search exists@ >> +local idexpression id; >> +expression x,e,e1; >> +position p1,p2; >> … >> +@@ >> + >> +id = of_find_device_by_node@p1(x) >> +... when != e = id >> … >> >> Or: >> >> … >> + ... when != id = e >> … >> >> >> Which SmPL specification will achieve the desired software

Re: [Cocci] [v6] coccinelle: semantic code search for missing put_device()

2019-02-18 Thread Markus Elfring
>>> Which data element should not get reassigned here (before a corresponding >>> null pointer check)? >>> >> >> Thank you for your comments. >> We did some experiments: >> +id = of_find_device_by_node@p1(x) >> +... when != e = id >> ... >> Or: >> ... >> + ... when != id = e >> >> The number of

Re: [Cocci] [PATCH v2] coccinelle: semantic patch for missing put_device()

2019-02-12 Thread Markus Elfring
> For c programmers, the first way of writing may be easier to understand; I suggest the reduction of a bit of redundant C code within SmPL search specifications. > in addition, the second way, its two brackets are not well aligned. There can be different preferences for the SmPL coding style

Re: [Cocci] [PATCH v3] Coccinelle: semantic patch for missing put_device()

2019-02-13 Thread Markus Elfring
> The of_find_device_by_node() takes a reference to the underlying device > structure, we should release that reference. I have got another concern for further software development considerations. How do you think about to describe here if it can be determined by source code analysis that the

Re: [Cocci] [v3] coccinelle: semantic patch for missing put_device()

2019-02-14 Thread Markus Elfring
> However, when we tried the following style, we encountered a parse error. I am sorry that my refactoring proposal did not completely fit to the applied software version. I am still curious if a development topic like “Support for SmPL disjunctions on every token” will evolve further.

Re: [Cocci] [v3] Coccinelle: semantic patch for missing put_device()

2019-02-14 Thread Markus Elfring
>> +when != ex = \( (T)id \| >dev \| get_device(>dev) \| >> (T1)platform_get_drvdata(id) \) > > There is no need for the disjunction. There is also no need for the > different variables. Really? Would you like to distinguish the shown assignment expressions anyhow? > Different variables

Re: [Cocci] [PATCH v4] coccinelle: semantic patch for missing put_device()

2019-02-14 Thread Markus Elfring
> The implementation of this semantic patch is: Thanks for your extension of such a commit message. I would interpret the provided SmPL code in the way that it will not generate adjusted (patched) C code so far. Source code search results will be presented by the operation mode “report” or

Re: [Cocci] [PATCH v3] coccinelle: semantic patch for missing put_device()

2019-02-13 Thread Markus Elfring
> Reviewed-by: Markus Elfring I have got doubts that my code review comments qualify already for this tag. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?id=1f947a7a011fcceb14cb912f5481a53b18f1879a#n565 > Cc:

Re: [Cocci] [v5] Coccinelle: semantic code search for missing put_device()

2019-02-15 Thread Markus Elfring
>>> +id = of_find_device_by_node@p1(x) … >>> +if (id == NULL || ...) { ... return ...; } >>> +... when != put_device(>dev) >> … >>> +when != if (id) { ... put_device(>dev) ... } >> … >> >> I would interpret this SmPL code in the way that the if statement >> for the pointer check is “optional”

Re: [Cocci] [PATCH v5] Coccinelle: semantic code search for missing put_device()

2019-02-15 Thread Markus Elfring
> +@search exists@ > +local idexpression id; > +expression x,e,e1; > +position p1,p2; > +type T,T1,T2,T3; > +@@ > + > +id = of_find_device_by_node@p1(x) > +... when != e = id > +if (id == NULL || ...) { ... return ...; } > +... when != put_device(>dev) … > +when != if (id) { ...

Re: [Cocci] [v5] Coccinelle: semantic code search for missing put_device()

2019-02-15 Thread Markus Elfring
>>> +id = of_find_device_by_node@p1(x) … >>> +if (id == NULL || ...) { ... return ...; } >>> +... when != put_device(>dev) >> … >>> +when != if (id) { ... put_device(>dev) ... } >> … >> >> I would interpret this SmPL code in the way that the if statement >> for the pointer check is “optional”

Re: [Cocci] [v5] Coccinelle: semantic code search for missing put_device()

2019-02-15 Thread Markus Elfring
>> Does the first SmPL when specification include the case that a call >> of the function “put_device” can occur within a branch of an if statement? > > It does include that, Thanks for this acknowledgement. So it seems that you find my interpretation of this bit of SmPL code appropriate. >

Re: [Cocci] Qualifiers for field types get lost

2019-02-15 Thread Markus Elfring
> There's a qualifier propagation issue left in the case the field is an array. > I have attached a patch that extends the tests/qualifier.c test case > to demonstrate the problem. Can the desired functionality check be performed also with a bit less source code by using the conditional operator?

Re: [Cocci] Qualifiers for field types get lost

2019-02-15 Thread Markus Elfring
> The generic transformation is simple but perfect at the same time and > showcases coccinelles expressiveness and beauty. Another “false positive leftover” pointed further software development opportunities out according to your suggestion “[PATCH] oleaut32/tests: Propagate the const instead of

Re: [Cocci] [v5] coccinelle: semantic code search for missingput_device()

2019-02-16 Thread Markus Elfring
>>> We don't need perfection. >> >> I guess that you noticed in the meantime that I dare to propose >> more software development efforts in such a direction. > > Yes, this is noticable. I am curious then if remaining change suggestions will be picked up by more software developers and reviewers.

Re: [Cocci] [v5] coccinelle: semantic code search for missingput_device()

2019-02-16 Thread Markus Elfring
> Thanks, We will change it to something like this: > In a function, for a local variable obtained by of_find_device_by_node() How do you think about another wording approach? 1. Precondition: It will be checked where the return value is stored from a call of the function

Re: [Cocci] [v5] Coccinelle: semantic code search for missing put_device()

2019-02-16 Thread Markus Elfring
>> We will modify the the if in the when code like this: >> >> @@ -22,7 +22,7 @@ if (id == NULL || ...) { ... return ...; } >> ... when != put_device(>dev) … >> -when != if (id) { ... put_device(>dev) ... } >> +when != if (...) { ... put_device(>dev) ... } > > This looks ok. I have got

Re: [Cocci] [v5] Coccinelle: semantic code search for missing put_device()

2019-02-16 Thread Markus Elfring
>> Thus I do not see a need (or requirement) for a duplicate search attempt. > > Why don't you actually try it and see what the difference is rather than > repeatedly giving false information? I suggest to clarify this software development disagreement by the following SmPL code. ... when !=

Re: [Cocci] [v5] coccinelle: semantic code search for missingput_device()

2019-02-16 Thread Markus Elfring
> We don't need perfection. I guess that you noticed in the meantime that I dare to propose more software development efforts in such a direction. > We need more to eliminate the memory leaks. Will this view evolve into further helpful and constructive clarifications? Regards, Markus

Re: [Cocci] [PATCH v2] coccinelle: semantic patch for missing put_device()

2019-02-11 Thread Markus Elfring
> +when != e4 = (T1)platform_get_drvdata(id) > +( > +return id; > +| > +return (T2)dev_get_drvdata(>dev); > +| > +return (T3)platform_get_drvdata(id); > +| > +return at p2 ...; > +) How do you think about to adjust this SmPL disjunction a bit like the following? +when != e4 =

Re: [Cocci] Searching for duplicate statements in if branches (with SmPL)?

2019-04-11 Thread Markus Elfring
> Your ifs may be in a loop. Such source code structures are actually shown for the first two diff hunks. Will any further adjustments be needed to take this aspect better into account for the presented analysis approach? Regards, Markus ___ Cocci

[Cocci] Searching for duplicate statements in if branches (with SmPL)?

2019-04-11 Thread Markus Elfring
Hello, I have constructed the following small SmPL script. @duplicated_code@ identifier work; statement s1, s2; type T; @@ T work(...) { ... when any *if (...) *{ ... when any * s1 * s2 *} ... when any *if (...) *{ ... when any * s1 * s2 *} ... when any } Test result:

Re: [Cocci] Searching for duplicate statements in if branches (with SmPL)?

2019-04-11 Thread Markus Elfring
> If you want to be sure that you aren't in a loop, I have got other expectations for the software behaviour. > you have to ue position variables to be sure that the two matched fragments > are different. I wonder how loops could matter for the presented analysis approach. Regards, Markus

Re: [Cocci] Checking the “display” of last two statements in code blocks

2019-04-12 Thread Markus Elfring
>> @@ -3015,11 +2859,6 @@ static int init_slave(struct gbe_priv *g >> } >> >> if (of_property_read_u32(node, "link-interface", >> ->link_interface)) { >> - dev_warn(gbe_dev->dev, >> -"missing link-interface value

Re: [Cocci] Clarification for SmPL asterisk functionality

2019-04-12 Thread Markus Elfring
> The asterisk functionality has no goal of making code that compiles. How do you think about to add this information to the manual for the semantic patch language? Regards, Markus ___ Cocci mailing list Cocci@systeme.lip6.fr

Re: [Cocci] Searching for duplicate statements in if branches (with SmPL)?

2019-04-12 Thread Markus Elfring
>>> If you want to be sure that you aren't in a loop, >> >> I do not want to filter on this implementation detail for the shown analysis >> approach. > > I don't know what you mean by "I do not want to". I suggest to improve this clarification by additional case distinctions. > You mean that

[Cocci] Checking the “display” of last two statements in code blocks

2019-04-12 Thread Markus Elfring
Hello, I have tried another small SmPL script out. @display@ identifier work; statement s1, s2; type T; @@ T work(...) { ... when any *{ ... when any * s1 * s2 *} ... when any } I have observed then that the following diff hunk was generated.

Re: [Cocci] Searching for duplicate statements in if branches (with SmPL)?

2019-04-12 Thread Markus Elfring
> If you want to be sure that you aren't in a loop, I do not want to filter on this implementation detail for the shown analysis approach. > you have to ue position variables to be sure that the two matched fragments > are different. I find this information questionable. * How should source

[Cocci] Searching for last two statements in code blocks

2019-04-18 Thread Markus Elfring
Hello, I have tried another small SmPL script out. @display@ identifier work; statement s1, s2; type T; @@ T work(...) { ... when any { ... when any *s1 s2 } ... when any } I have observed that no statements were shown from if branches in my test source file. This happened then after

Re: [Cocci] Add code after local variable declarations?

2019-04-17 Thread Markus Elfring
>> Would you like to add any source code only after a variable declaration > > Coccinelle doesn't allow this. It has no way of knowing whether other > declarations come afterwards, I suggest to reconsider this quick response. Are there approximations supported for such a source code search

Re: [Cocci] Add code after local variable declarations?

2019-04-17 Thread Markus Elfring
>> Would you like to add any source code only after a variable declaration > > Coccinelle doesn't allow this. It has no way of knowing whether other > declarations come afterwards, I suggest to reconsider this quick response. Are there approximations supported for such a source code search

Re: [Cocci] Working with backreferences in SmPL scripts?

2019-04-17 Thread Markus Elfring
> A metavariable is always bound to the same value within a given > control-flow path. Thanks for this information. > I have no idea what you are trying to get at with this example. Some goals can match to my use case description. * Is another nice refactoring application demonstrated for

[Cocci] Working with backreferences in SmPL scripts?

2019-04-17 Thread Markus Elfring
Hello, I have tried another small SmPL script out. @replacement@ expression ex; identifier var; @@ var - = var + + += ex elfring@Sonne:~/Projekte/Coccinelle/Probe> spatch simplify_addition1.cocci Test_increment1.c … @@ -1,6 +1,6 @@ int main(void) { int counter = 3;

Re: [Cocci] Add code after local variable declarations?

2019-04-17 Thread Markus Elfring
> @@ > statement S,S1; > @@ > > foo(...) { > ... when != S > + added code > S1 > ... > } > > A declaration doesn't match S. Can this information trigger additional considerations for the handling of variable definitions? Would you like to add any source code only after a variable

Re: [Cocci] Checking influence of loops?

2019-04-13 Thread Markus Elfring
>>> If you have a pattern like >>> >>> AAA >>> ... >>> BBB >>> >>> The AAA and BBB might match the same code >> >> I agree to this information in principle. >> But I imagine that this source code should be found >> at different positions. > > No there is no such constraint. My software

Re: [Cocci] Checking influence of loops?

2019-04-13 Thread Markus Elfring
> Your ifs may be in a loop. Does your technology treat this control flow in special ways? Regards, Markus ___ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] Checking influence of loops?

2019-04-13 Thread Markus Elfring
>>> Your ifs may be in a loop. >> >> Does your technology treat this control flow in special ways? > > No. Would the quoted information be irrelevant then for the discussed use case? Regards, Markus ___ Cocci mailing list Cocci@systeme.lip6.fr

Re: [Cocci] Checking influence of loops?

2019-04-13 Thread Markus Elfring
>> Should two search specifications (with SmPL ellipses) between them >> be kept separate for the desired diff output? > > I don't understand any of your answers precisely. I hope that we can come closer again to a better understanding of the reported software situation. > If you have a pattern

Re: [Cocci] Checking influence of loops?

2019-04-13 Thread Markus Elfring
> Your ifs may be in a loop. Does your technology treat this control flow in special ways? >>> >>> No. >> >> Would the quoted information be irrelevant then for the discussed use case? > > No idea what the above means. It seems that there is another communication difficulty

Re: [Cocci] Checking influence of loops?

2019-04-13 Thread Markus Elfring
>>> Typically when there is a loop or goto. >> >> I find such a case distinction interesting. >> >> >>> But there is no special handling of either construct. >> >> Does this information contain a contradiction? > > No. Draw a control flow graph of a loop and see what should happen for > such a

Re: [Cocci] Clarification for SmPL ellipsis functionality

2019-04-13 Thread Markus Elfring
>> I am still curious if it can be achieved that two statements >> (with a SmPL ellipsis between them) will be found only at different >> positions. >> >> How should be excluded that two generic search specifications >> will be merged? > > Use position variables and use a second rule that forces

Re: [Cocci] Clarification for SmPL functionality around position variables

2019-04-14 Thread Markus Elfring
> Use position variables and use a second rule that forces the positions to > be different. I already explained this. I suggest to take another look at the provided information. I have extended the analysis approach like the following. @find@ identifier work; position p1, p2; statement s1,

Re: [Cocci] Clarification for SmPL functionality around position variables

2019-04-14 Thread Markus Elfring
Variable find.p2 in duplicated_code cannot be used as both a position and a constraint >>> >>> I think that you have to declare find.p1 and find.p2 on a subsequent line. >> >> I have observed the same error message then. > > Go back and read what I wrote. I suggest to take another look

Re: [Cocci] Clarification for SmPL functionality around position variables

2019-04-14 Thread Markus Elfring
>> elfring@Sonne:~/Projekte/Coccinelle/janitor> spatch --parse-cocci >> show_same_statements7.cocci >> … >> Variable find.p2 in duplicated_code cannot be used as both a position and a >> constraint > > I think that you have to declare find.p1 and find.p2 on a subsequent line. I have observed

Re: [Cocci] Clarification for SmPL functionality around position variables

2019-04-14 Thread Markus Elfring
>> I tried three different orderings out for these position variables >> in the meantime. >> >> Will the implementation be fixed for all affected software components anyhow? > > No. I am still curious then under which circumstances this software will be corrected. Regards, Markus

Re: [4/5] Coccinelle: put_device: Extend when constraints for two SmPL ellipses

2019-05-15 Thread Markus Elfring
> Could we use it to find out as many bugs as possible in the current kernel How do you think about to work with any more source code analysis approaches? > and then modify it? I guess that you do not need to wait for a solution so long. Variables which get reassigned in unwanted ways (before

Re: Coccinelle: semantic patch for missing of_node_put

2019-05-17 Thread Markus Elfring
> 1, A simple method. > We did some experiments, and we could get the list of functions that need to > be considered directly through this script: > > $ spatch --tokens-c drivers/of/base.c 2>&1 | grep "Tag3 " | grep > "of_node_put() on it when done." | awk -F " - " '{print $1}' | grep -o >

Re: Coccinelle: semantic patch for missing of_node_put

2019-05-17 Thread Markus Elfring
> A semantic patch has no access to comments. Thanks for your acknowledgement of the current situation. > The only thing I can see to do is to use python to interact with some > external tools. I see more software development possibilities. * Advanced data processing for source code comments

Re: [Cocci] Checking change scope for a data type replacement

2019-05-27 Thread Markus Elfring
> Am I missing something? It depends on details. Your initial transformation approach can be written also as follows. @replacement@ identifier x; @@ -int +int* x; In which scopes would you like to add the asterisk for the usage of a pointer data type? Do you expect that function parameters

Re: [Cocci] Checking structures for usage of OCaml variables with inherited SmPL data

2019-05-27 Thread Markus Elfring
> Besides comments, everything is either a string or a position, > ie type pos list, where the type pos is found in man Coccilib. How do you think about to improve the programming interface descriptions here? Which data structures would be relevant for the metavariable “identifier”? Do they

[Cocci] Checking structures for usage of OCaml variables with inherited SmPL data

2019-05-27 Thread Markus Elfring
Hello, The semantic patch language supports also the specification and handling of OCaml script rules. Inherited SmPL variables can be connected to corresponding local variable names. I would appreciate if the determination of the provided data structures can become easier. * Which data types

Re: [Cocci] Checking change scope for a data type replacement

2019-05-27 Thread Markus Elfring
>> @replacement@ >> identifier x; >> @@ >> -int >> +int* >>   x; > >> >> In which scopes would you like to add the asterisk for the usage of a pointer >> data type? … > 1) "x" has a type of "int *" The asterisk addition seems to work for (local) variables. > 2) the new "int *x" gets passed to a

Re: [Cocci] Changing include parameters for compilation of OCaml code from SmPL scripts

2019-05-25 Thread Markus Elfring
>> ocamlc.opt -c /tmp/ocaml_cocci_bbc38d.cmo -g -I >> /home/elfring/Projekte/Coccinelle/20160205/ocaml -I /usr/lib64/ocaml >> /tmp/ocaml_cocci_bbc38d.ml How can it be achieved to replace the shown reference to a directory of the (standard) library for the system OCaml compiler?

Re: [Cocci] Checking change scope for a data type replacement

2019-05-27 Thread Markus Elfring
> In other words, in my original code "int x" is passed to "void f(int)" as a > paramter, > and I would like to apply the following transformations: How do you think about to try a SmPL change specification out like the following? @replacement3@ identifier x; @@ -int +int* x; <+... -f +g

Re: [Cocci] "depends on" per file

2019-05-27 Thread Markus Elfring
> The issue is that if the rule gets matched in one file, > it will include the header in every other file as well, How did you choose the selected source file combination? > because the "depends on ever" clause is satisfied. > Is there a way to tell coccinelle "apply this rule to file X, > but

Re: [Cocci] Checking change scope for a data type replacement

2019-05-27 Thread Markus Elfring
>> @replacement3@ >> identifier x; >> @@ >> -int >> +int* >> x; >> <+... >> -f >> +g >> (x); >> ...+> > > His example shows that he wants to change a parameter type, He would like to call a function which gets a single pointer passed instead of an integer by possibly varying variables. >

Re: [Cocci] accessing comments

2019-05-25 Thread Markus Elfring
> You get a list of strings, with one comment per string. It seems that this metavariable provides structured information which can be split according to your OCaml code in the SmPL script. “… let (c1b,c1m,c1a) = List.hd c1 in …” Can this programming approach result in undesirable data

Re: [Cocci] accessing comments

2019-05-25 Thread Markus Elfring
>> “… >> let (c1b,c1m,c1a) = List.hd c1 in >> …” >> >> >> Can this programming approach result in undesirable data duplication? > > There is no data duplication. The involved data structures are unclear at the moment. > Learn about pointers. How many different pointers will refer to empty

Re: [Cocci] accessing comments

2019-05-25 Thread Markus Elfring
> There is one in an argument list that is within a statement. This would only matter for the second call of the function “foo” in the example function “main”, wouldn't it? https://github.com/coccinelle/coccinelle/blob/210ce894d2dd1572fff9e1c98ae443e6df14f4c7/demos/comments.c#L2 How does your

Re: [Cocci] accessing comments

2019-05-25 Thread Markus Elfring
> There is one in an argument list that is within a statement. Can it be that such a comment would belong to the function call operator (open or closing parenthesis) instead of the identifier “foo”? Regards, Markus ___ Cocci mailing list

Re: [Cocci] accessing comments

2019-05-25 Thread Markus Elfring
>> * Now I wonder why this display is presented in three variations. > > Before within and after I find this software behaviour hard to understand at the moment when the shown metavariables were split into three parts already by the call of the OCaml function “List.hd”. Which comment would be

Re: [Cocci] accessing comments

2019-05-25 Thread Markus Elfring
>> How does your software decide which comment should be treated >> as simple text before or after an item? > > It takes all of the comments before (up to the preceding non comment > token if any) within and after (up to the following non comment token > if any). I find that this information can

Re: [Cocci] accessing comments

2019-05-26 Thread Markus Elfring
>> How often will it matter if only one item is involved instead of >> several places? > > Your approach introduces pointless complexity to distinguish between th > different cases. I got an other software development opinion. It might take another while to agree on useful case distinctions. Do

Re: [Cocci] accessing comments

2019-05-26 Thread Markus Elfring
>> * How do you think about my expectation that the OCaml script rule >>   should be evaluated only once because a single function implementation >>   example is analysed here? > > The multiple times have to do with the ... not the comment variables. I do not expect so far that the SmPL code “...

Re: [Cocci] accessing comments

2019-05-26 Thread Markus Elfring
> You can attach a comment metavariable to any token in the semantic patch. > some of these are metavariables. Metavariables (except identifier > metavariables) often match more than one token in the C code. Can this case distinction trigger corresponding software design adjustments? How often

Re: [Cocci] accessing comments

2019-05-26 Thread Markus Elfring
>> Will data structures become helpful where less than three attributes >> would be provided because a special source code element would be selected? > > Stop the pointless micro optimization. This has no impact on anything. We got different programming views which influence another approach to

Re: [Cocci] accessing comments

2019-05-26 Thread Markus Elfring
> Parameter lists are irrelevant. That is just an example. We have got a different understanding for the desired comment handling there at the moment. > As long as the SmPL token matches more than one token, Would we like to distinguish and clarify this case any further? > it is possible

Re: [Cocci] accessing comments

2019-05-26 Thread Markus Elfring
>> How many different pointers will refer to empty strings here? > > None. If there is no comment, it will be the empty list. How many different pointers can occur for these empty items? > The before, within and after comments are lists of strings. Will data structures become helpful where

  1   2   3   4   5   6   7   8   9   10   >