Hello,
The semantic patch language supports to search for various identifiers
in source files. It is often hoped then that a found identifier fits to
a known application context.
But it can happen with generic source code analysis approaches that
a desirable confidence level can not easily be
> I think that you just want to disable the isomorphism. Put disable neg_if
> in the initial @@ of your rule.
>>
>> Will a need evolve to switch isomorphisms completely off for safer
>> (and efficient) analysis of original source code?
Will the corresponding system configuration get any
>> I would find it nice to explain the different software behaviour for the
>> mentioned
>> SmPL code variants
>
> Run spatch -parse-cocci and you will easily see. The if stays in the same
> place. When the isomorphism exchanges the branches, the condition gets
> negated, so in one case you get
>>> Maybe you consider the following results to be a problem:
>>>
>>> kzalloc mcde [("mcde_probe", 2, 0, 198, 1, "m.c", 16, 1, 16, 3)]
>>> kzalloc ! mcde [("mcde_probe", 2, 0, 198, 1, "m.c", 16, 1, 16, 3)]
>>> platform_get_irq irq [("mcde_probe", 2, 0, 198, 1, "m.c", 97, 1, 97, 3)]
>>>
> Maybe you consider the following results to be a problem:
>
> kzalloc mcde [("mcde_probe", 2, 0, 198, 1, "m.c", 16, 1, 16, 3)]
> kzalloc ! mcde [("mcde_probe", 2, 0, 198, 1, "m.c", 16, 1, 16, 3)]
> platform_get_irq irq [("mcde_probe", 2, 0, 198, 1, "m.c", 97, 1, 97, 3)]
> platform_get_irq ! irq
> @script:ocaml@
> action << find.action;
> check << find.check;
> p << find.p;
> @@
> Printf.printf "%s %s %s\n" action check (Dumper.dump p)
>
> On the code you provided whichis unfortunately much too long to include in
> a message
I found my code examples short enough.
> and that you could
>> How will the application of SmPL conjunctions evolve further?
>
> I really have no idea what you are talking about.
I suggest to take another look at affected implementation details.
> Make one single mail that contains all of the semantic patch variants
> that you want to have considered
>> Do I present another advanced use case for the application of known software
>> tools?
>
> No.
Such a view can be also interesting.
> The faults in linux paper (work done 10 years ago) uses a database as well.
Thanks for this background information.
How will the software evolve further in
> Now you have the two scripts, which is good, but you haven't included the
> test data that causes the problem. Please make one mail that includes
> everything.
I find that I provided relevant data already.
https://systeme.lip6.fr/pipermail/cocci/2020-April/007135.html
>>> The database itself doesn't bring any value.
>>
>> Another unique constraint violation was noticed by using such technology.
>
> It's an accident.
This might be. - I got into the development mood to publish patches
for a few source files of Linux modules according to another search approach.
>> I observe that the following SmPL code variant can result also in
>> a significant difference.
>>
>> @find@
>> expression action, check, result;
>> position p;
>> statement is, es;
>> @@
>> result = action(...);
>> if (
>> ( <+... result ...+>
>> & check@p
>> ) )
>> is
>> else
>>
> I hope that it can become easier to clarify where unexpected duplicate keys
> would occur as in my test approach.
There is the possibility to apply information according to a clarification
request on a topic like “Checking the handling of unique keys/indexes”
from 2014-12-20.
>> I hope that it can become easier to clarify where unexpected duplicate keys
>> would occur as in my test approach.
>
> Use --debug and just print out the infomation rather than putting is in
> your database.
We have got different views around this logging approach.
> With the database you
> I think that your issue about something matching or not has nothing to do
> with the database code, and you could easily remove it for the purposes of
> reporting a concern with Coccinelle.
Software evolution can be continued also together with your constructive
feedback.
I adapted another
>> Can the matched source code from the construct “<+... e ...+>” be assigned
>> to a metavariable like “check”?
>
> (
> <+... e ...+>
> &
> check
> )
Did I just stumble on incomplete knowledge for the safe application
of the conjunction functionality with the semantic patch language?
It
@display2@
expression check;
position display1.p;
statement display1.is, display1.es;
>>>
>>> The problem is that you inherit es. Since you inherit it, Coccinelle
>>> considers that its presence is important, and so the isomorphism will not
>>> eliminate it.
>>
>> Thanks for
>> @display1@
>> expression action, e;
>> position p;
>> statement is, es;
>> @@
>> *e = action(...);
>> if@p (<+... e ...+>)
>> is
>> else
>> es
>>
>> @display2@
>> expression check;
>> position display1.p;
>> statement display1.is, display1.es;
>
> The problem is that you inherit es.
>> I hope that another clarification can be achieved also for the software
>> behaviour of the following source code analysis approach.
>
> I don't run code that involves databases. If you believe that there is a
> problem with the semantic patch, you have to make a small version that
>
> I noticed that there was a report about an isomorphism not applying.
I hoped for another clarification also for the message “warning: iso drop_else
does not match the code below on line 55” (and the corresponding debug display).
> That issurely the problem. So you have to figure out why it
> I think that your issue about something matching or not has nothing to do
> with the database code,
Such a view can be partly appropriate.
> and you could easily remove it
I hope that the understanding of the presented SmPL code example
could also be sufficient in the way that the data
>> I hope that another clarification can be achieved also for the software
>> behaviour of the following source code analysis approach.
>
> I don't run code that involves databases.
Can the situation evolve in a way so that this programming interface
will become better supported together with
>> I hope that another clarification can be achieved also for the software
>> behaviour of the following source code analysis approach.
>
> I don't run code that involves databases.
I find the handling of higher level data storage relevant and useful
also for such a software test.
> If you
> If you want something done, please do it yourself.
I hope that another clarification can be achieved also for the software
behaviour of the following source code analysis approach.
@initialize:python@
@@
import sqlalchemy, sys
sys.stderr.write("\n".join(["Using SQLAlchemy version:",
>> Would you like to display statistics around the distribution of condition
>> checks after function calls (with help of the semantic patch language)?
>
> I'm working on other things.
Thanks for your feedback.
> If you want something done, please do it yourself.
I assumed that you (or other
> Maybe you can just take inspiration from this paper:
>
> https://pages.lip6.fr/Julia.Lawall/dsn09.pdf
I got another idea which can be related to information from the section
“Case Study: Inconsistent Error Checks” in your document “WYSIWIB:
A Declarative Approach to Finding API Protocols and
> Analysing each matching case would take a lot of time.
How many efforts would you like to invest in adjusting the situation?
Will any more development possibilities picked up to reduce the presentation
of false positives by the mentioned source code analysis approach considerably?
Regards,
> Maybe you can just take inspiration from this paper:
>
> https://pages.lip6.fr/Julia.Lawall/dsn09.pdf
I find the information from this document “WYSIWIB: A Declarative Approach
to Finding API Protocols and Bugs in Linux Code” also interesting.
Did the mentioned tools “Search”, “Instantiate”,
Hello,
Several functions for a programming language like C are designed in the way
that values are returned by an integral data type.
Specific value ranges can indicate then a failed function call.
A well-known variant of this design pattern is that negative return values
represent failures
>> * The source code search pattern can be too generic.
>> How do you think about to consider additional constraints
>> for safer data control flow analysis?
>
> Could you please elaborate on that?
Julia Lawall chose to mention the design possibility “put when
!= mutex_lock(E) after the ...”.
> What should I be looking for in the archives?
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/scripts/coccinelle/api/alloc/zalloc-simple.cocci?id=dfd32cad146e3624970eee9329e99d2c6ef751b3
Several software development discussions might be interesting
also before the
> Do you have any idea how to improve it?
I see further software development possibilities of varying relevance
also for this script of the semantic patch language.
* The SmPL variables “lock_p”, “unlock_p” and “stop_p” could be declared
in a more succinct way just by listing them in the same
>> Will the software development attention grow in a way so that further
>> implementation details can be adjusted also for the mentioned SmPL script?
>
> I'm not sure I understand what you mean. Would you mind clarifying?
You would like to a change a file for which some software development
> * spatch seems to have trouble parsing
>
> ARMSSE *s = ARMSSE(opaque);
>
> where ARMSSE is a typedef, and ARMSSE() is a function-like macro.
> Yes, I know that's in rather poor taste.
I am curious for the safe handling of related software development challenges.
> * Workaround #1:
> Commit dfd32cad146e ("dma-mapping: remove dma_zalloc_coherent()"), in
> removing dma_zalloc_coherent() treewide, inadvertently removed the patch
> rule for dma_alloc_coherent(), leaving Coccinelle unable to auto-generate
> patches for this case. Fix this.
I suggest to reconsider also the
> Wonder harder.
>
> If something is (& 3) it is also either (& 2 || & 1)
> so why have both below the first test?
Would you occasionally prefer to use enumeration values together with
switch statements at such source code places?
Regards,
Markus
___
> Wonder harder.
>
> If something is (& 3) it is also either (& 2 || & 1)
> so why have both below the first test?
I can interpret the source code example in the way that the number
of set bits are checked.
I can eventually become concerned around the preferred coding style
because of the usage
> There is a block of if tests against the same variable
> in include/linux/mtd/pfow.h that likely is defective
I wonder about this interpretation.
> Likely the first test should be something like
>
> if ((prog_status & 0x03) == 0x03)
Why would you prefer such a code variant?
> Is
>> How will the support evolve for data processing around the application
>> of similar macros?
>
> Not at all.
Will such feedback trigger any collateral evolution?
Regards,
Markus
___
Cocci mailing list
Cocci@systeme.lip6.fr
>> …
>> (ONCE) CPP-MACRO: found known macro = FNAME
>> …
>> parse error
…
>> How would you like to improve the affected software areas?
>
> This can be addressed by adding a macro definition to standard.h.
A corresponding specification is used already.
>> How will corresponding software development resources evolve?
>
> I don't think I understand the question, or, actually, are you asking
> me or the coccinelle developers ?
I hope that more development challenges will be picked up.
The code from a mentioned source file can be reduced to the
> This discussion is about parsing the source code.
It seems that an acceptable solution was found according to your advice
yesterday.
I could offer other ideas for another bit of software fine-tuning.
Regards,
Markus
___
Cocci mailing list
> I have this all working with the following script with the caveat that
> running it on moderately complicated source files makes it never
> finish (after an hour or so the spatch process crashes with a stack
> overflow error).
Do you find any information interesting from a previous bug report?
> The problem can be seen with the --debug option:
>
> FLOW: can't jump to VMALLOC_FAULT_TARGET: because we can't find this label
>
> It's not apparent with the --parse-c option because it's not a parsing
> problem.
Thanks for such information.
Can the example be transformed even if extra
>> How would you like to fix this situation?
>
> Who exactly do you think "you" is?
Every contributor with helpful software development resources for this issue.
> I will look at it,
Thanks for another promising feedback.
> but it is not very polite to ask a user of Coccinelle such a
>> How will corresponding software development resources evolve?
>
> I don't think I understand the question, or, actually, are you asking
> me or the coccinelle developers ?
I hope that another communication approach can eventually increase
the chances for a better common understanding of
> I would be interested to find out why coccinelle wasn't able to do the
> last 1%, but only as part of a long-term learning process on getting
> better with coccinelle - …
How will corresponding software development resources evolve?
Regards,
Markus
> Convert the last few remaining mmap_sem rwsem calls to use the new
> mmap locking API. These were missed by coccinelle for some reason
Will the clarification of this software situation become more interesting?
> (I think coccinelle does not support some of the preprocessor
> constructs in
> Convert the last few remaining mmap_sem rwsem calls to use the new
> mmap locking API. These were missed by coccinelle for some reason
I find such a software situation still unfortunate.
* Should the data processing results be clarified any further
for the shown transformation approach?
*
>>> The change is generated using coccinelle with the following rules:
>>
>> Would you like to apply only a single SmPL rule here?
>
> I think this version of the patch is already a single rule,
> similar to what you suggested ?
Yes. - But you repeated the wording “rules” in the change
> This change converts the existing mmap_sem rwsem calls to use the new
> mmap locking API instead.
>
> The change is generated using coccinelle with the following rules:
Would you like to apply only a single SmPL rule here?
> // spatch --sp-file mmap_lock_api.cocci --in-place --include-headers
> Convert the last few remaining mmap_sem rwsem calls to use the new
> mmap locking API. These were missed by coccinelle for some reason
I find such a software situation unfortunate.
Should the transformation approach be clarified any further?
Regards,
Markus
>> I have noticed the patch “tty: serial: fsl_lpuart: fix return value
>> checking”.
>> https://lore.kernel.org/linux-serial/20200325090658.25967-2-mich...@walle.cc/
…
> I'm not sure what there is to clarify. One can surely write rules that
> find this kind of problem, with a varying rate of
>> I have noticed the patch “tty: serial: fsl_lpuart: fix return value
>> checking”.
>> https://lore.kernel.org/linux-serial/20200325090658.25967-2-mich...@walle.cc/
…
> I'm not sure what there is to clarify.
Such an use case can point some software development challenges out.
> One can surely
Hello,
I have noticed the patch “tty: serial: fsl_lpuart: fix return value checking”.
https://lore.kernel.org/linux-serial/20200325090658.25967-2-mich...@walle.cc/
https://lore.kernel.org/patchwork/patch/1215542/
https://lkml.org/lkml/2020/3/25/202
I am curious if such a software transformation
> The order of the terms in ParenType require implementing a special
> case for ParenType. This case handles only the following:
* Would it be nice to mention a key word like “parentheses”?
* How do you distinguish “visitors” for the affected software?
* I would prefer less repeated change
> ParenType and FunctionType are types present in the C AST that
> are not present in the SmPL AST.
Can the understanding of mentioned details be improved by reconsidering
the usage of abbreviations?
> In the pursuit of aligning both the C and SmPL ASTs,
I find this approach also helpful.
>
> One of the hardest things in dealing with a community is to learn who to
> ignore when it comes to patch reviews and comments.
I suggest to reconsider also this information once more.
> Just a friendly reminder that this person is on many upstream kernel
> developer's
> email-block lists due
> Changes in v2:
> …
> - Change the "visitor_ast0" in patch subject to "visitor_ast"
Thanks for such a software update.
I suggest to reconsider the patch granularity once more.
Would you like to reduce the possibilities for confusion around
the presented software transformation?
Regards,
Markus
>> I got special views also around patch squashing.
>> Would you like to reduce the number of update steps
>> according to the really desired software transformation?
>
> I asked him to cut it up into small chunks.
We come along different preferences for the size of these pieces.
Regards,
Markus
>> How do you think about to combine such changes in a bigger update step?
>
> These are separated this way so that it's easier for Julia to review.
I suggest to reconsider such an approach.
> She will probably just squash all 26 of these together and apply them later.
I got special views also
> ParenType and FunctionType are added to the SmPL ASTs.
> Add cases for these types in ….ml.
A change description template was used several times.
I wonder if there is really a need to modify only a single OCaml source file
in these update steps.
How do you think about to combine such changes in
> The order of the terms in ParenType require implementing a special
> case for ParenType. This case handles only the following:
…
It seems that this change description was repeated in other update steps.
Does this detail indicate a need to reconsider the patch granularity?
Regards,
Markus
> ParenType and FunctionType are types present in the C AST that
> are not present in the SmPL AST.
Will a bit more background information become helpful for these data types?
Regards,
Markus
___
Cocci mailing list
Cocci@systeme.lip6.fr
> Thus, a slightly hacky approach is taken to determine a function
> prototype with not the best certainty but what works for most cases
> in SmPL. If the identifier is preceded by any token that does not
> seem to be part of a type, then it is not identified as a function
> prototype. Else, it
> The aim of this patch series is to add the types ParenType
Can it be that this kind of data processing will need a bit more explanation?
> The FunctionPointer type is removed from the SmPL AST, since
> all the productions that produce FunctionPointers in the SmPL
> parser are replaced by
Hello,
Can any circumstances evolve under which you would like to perform
data processing by the programming means of a software framework
which would be similar to GStreamer?
https://gstreamer.freedesktop.org/features/
https://opam.ocaml.org/packages/gstreamer/
Regards,
Markus
>>> pointer == NULL would have been sufficient (not related to the noted
>>> problems).
>>
>> Should this detail be handled as an isomorphism?
>> https://github.com/coccinelle/coccinelle/blob/19ee1697bf152d37a78a20cefe148775bf4b0e0d/standard.iso#L134
>
> Yes.
Unfortunately, I might stumble still
>> ... when any
>> when != pointer = \( action(...) \| x \)
>> *if (
>> (!pointer
>> |pointer == NULL
>> )
>
> pointer == NULL would have been sufficient (not related to the noted
> problems).
Should this detail be handled as an isomorphism?
> minused assigned enumerators, plussed assigned enumerators
Does this description contain typos?
Regards,
Markus
___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci
> as well as adding the additional arguments needed in the visitor
How do you think about to reconsider such a wording?
Regards,
Markus
___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci
> The SmPL AST0 visitor has functions for handling enumerators
> separately. Handle these collateral evolutions in parsing_cocci
I got the impression that an other change description would be easier to
understand.
Regards,
Markus
___
Cocci mailing
> constructs w/r/t changes in the SmPL AST.
Would an other change description be more helpful?
Regards,
Markus
___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci
> Make the enumerator type of the SmPL AST closer to that of
> the C AST.
Are any deviations between these data structures still relevant
(or undesirable)?
Regards,
Markus
___
Cocci mailing list
Cocci@systeme.lip6.fr
> The C AST and SmPL AST differs with respect to the enum type.
I suggest to consider wording variants.
“The … and … differ ….”
> collateral evolutions caused by changed in the SmPL visitors are
“… by changes in …”
Regards,
Markus
___
Cocci mailing
Hello,
I have tried the following small script variant out again for
the semantic patch language.
@display@
expression action;
expression* pointer, target, x;
identifier member, var;
statement is;
type t;
@@
(
*t* var = pointer->member;
|
*pointer->member;
|
*target = pointer->member;
|
*t* var
> Why do you want to know?
I am looking for related incentives to achieve further progress
around affected areas.
Regards,
Markus
___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci
> I cloned coccinelle's GIT repository, I suggested a patch,
> and the patch has been accepted.
Will the chances increase for further contributions?
Regards,
Markus
___
Cocci mailing list
Cocci@systeme.lip6.fr
> And because Coccinelle is free software, I could inspect
> Coccinelle and even adapt a few minimal things to my needs!
Would you like to share a bit more information about such adjustments?
> And, dear Coccinelle devels, what we users can do to ensure
> good health to the Coccinelle project
> > Do you mean that the C file/res file should conform to the Linux style?
>
> I think it would be nicer if it did.
Is the interest for the clarification of a topic like “Make change influence
configurable for coding style rules” growing?
https://github.com/coccinelle/coccinelle/issues/37
>> https://en.wikipedia.org/wiki/AST
>
> Not necessary. Anyone who is looking at the Coccinelle commits should
> know what an AST is.
I would appreciate to reduce the potential for confusion around
the application of parsing technologies.
Regards,
Markus
> For a pointer, the C parser constructed an AST dissimilar from that
I find it helpful to mention the meaning of the term “AST” without abbreviation
for a nicer patch description.
https://en.wikipedia.org/wiki/AST
Regards,
Markus
___
Cocci mailing
> + const char *const *y;
> }
>
> There should be a space between * and const on the + line.
Will such a detail become more interesting for the clarification
around coding styles?
https://github.com/coccinelle/coccinelle/issues/37
Regards,
Markus
> Like what?
Do find my corresponding previous suggestion reasonable?
https://lore.kernel.org/cocci/702596c2-84bf-13ca-b014-8784bbb98...@web.de/
https://systeme.lip6.fr/pipermail/cocci/2020-February/006842.html
Regards,
Markus
___
Cocci mailing list
> This series is to address …
Under which circumstances would you choose an adjusted wording for the message
in the cover letter?
Regards,
Markus
___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci
>> REQUIRE((
>> - (T*)
>> source) != NULL);
>
> Thanks, that’s helpful.
Thanks for such a view on the suggested transformation approach.
>>> REQUIRE((
>>> - (T *)
>>> + (dns_rdatacommon_t *)
>>
>> (
>> -T
>> +dns_rdatacommon_t
>> *)
>
> This cannot be done,
I propose to take
Can the following transformation variants be also helpful?
> @@
> type T;
> expression source;
> @@
>
> - REQUIRE(((T *)source) != NULL);
> + REQUIRE(source != NULL);
REQUIRE((
- (T*)
source) != NULL);
> @@
> type T;
> type R;
type T;
> identifier common, rdtype;
> T
> > I must be missing something very obvious as just removing the type works,
> > but adding the `+ (dns_rdatacommon_t *)` line makes the rule fail.
>
> Coccinelle is not able to infer typedefs in casts.
Under which circumstances can this software situation be reconsidered?
How long will an
> A little collection of scripts/tools I've written[1],
Thanks for your link on another bit of background information.
https://github.com/jajajasalu2/cocci-type-test-suite
Would you like to point any related information sources out?
> and the invaluable OCaml debugger :)
This development tool
> A little collection of scripts/tools I've written[1],
Thanks for your link on another bit of background information.
https://github.com/jajajasalu2/cocci-type-test-suite
Would you like to point any related information sources out?
> and the invaluable OCaml debugger :)
This development tool
> > minus: parse error:
> > File "test.cocci", line 3, column 15, charpos = 38
> > around = 'p',
> > whole content = - g_autoptr(d) p;
> >
> >
> > is it correct?
>
> No, Coccinelle knows nothing about these things.
How are the chances to improve the software situation
for the safe handling
> For a pointer, the C parser constructed an AST dissimilar from that
> of the Cocci AST. This caused failures in matching with certain
> pointer types. For example, for the following case:
>
> char *1 const *2 id;
>
> The C AST constructed would be:
> const Pointer1 -> Pointer2 -> char
>
> The
>> * Should the potential for differences in these “AST” be checked any more?
>
> An effort is already being made to do this by me and Julia :)
I am curious how this collaboration will evolve further.
>> * How can such items be compared safely?
>
> Not sure what you mean. If you mean how the
> Would the following be a better subject?
The alternative is nicer.
Will other implementation details become also more interesting?
The information “Align C AST and Cocci AST” was provided.
https://lore.kernel.org/cocci/20200205130327.6812-2-jaskaransingh7654...@gmail.com/
> Would the following be a better subject?
I find the alternative succinct.
Regards,
Markus
___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci
Would you like to avoid any abbreviations in the patch subject?
> These types would not match previously.
I imagine that this information can be improved for a nicer patch description,
can't it?
Regards,
Markus
___
Cocci mailing list
…
> +++ b/parsing_c/pretty_print_c.ml
> @@ -804,11 +804,12 @@ and pp_string_format (e,ii) =
> (FunctionType (return=void, params=int i) *)
>(*WRONG I THINK, use left & right function *)
>(* bug: pp_type_with_ident_rest None t; print_ident ident *)
> +
> This series is to address the type matching problem in Coccinelle.
How do you think about the wording “This series addresses a type matching
problem
in the Coccinelle software.”?
Regards,
Markus
___
Cocci mailing list
Cocci@systeme.lip6.fr
> Coccinelle could provide an appropriate running time by just ignoring the
> <+... ...+>. But that seems like a pointless optimization, when the user
> could just not put the <+... ...+> in the first place.
I would like to express a specific SmPL functionality.
> Coccinelle already applies a
> Perhaps, but it will unnecessarily raise the running time of your semantic
> patch.
We come along different expectations again for the possible application
of the construct “<+... … ...+>” for the semantic patch language.
Should the concrete run time characteristics be clarified any more
for
>> @replacement@
>> constant c;
>> identifier text;
>> statement is, es;
>> @@
>> <+...
>
> What is thhe point of the outer <+... ...+>?
I would like to stress the possibility that source code adjustments
can be performed multiple times.
201 - 300 of 1468 matches
Mail list logo
